目录

Table of Contents

第三页

Page iii

软件工程

Software Engineering

实践者的方法

A Practitioner’s Approach

第九版

NINTH EDITION

罗杰·普雷斯曼博士

Roger S. Pressman, Ph.D.

布鲁斯·马克西姆博士

Bruce R. Maxim, Ph.D.

第四页

Page iv

软件工程:从业者的方法

SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH



由 McGraw-Hill Education 出版,地址:2 Penn Plaza, New York, NY 10121。版权所有 © 2020 McGraw-Hill Education。版权所有。美国印刷。未经麦格劳-希尔教育事先书面同意,不得以任何形式或任何方式复制或分发本出版物的任何部分,或将其存储在数据库或检索系统中,包括但不限于在任何网络或其他地方电子存储或传输,或用于远程学习的广播。

Published by McGraw-Hill Education, 2 Penn Plaza, New York, NY 10121. Copyright © 2020 by McGraw-Hill Education. All rights reserved. Printed in the United States of America. No part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written consent of McGraw-Hill Education, including, but not limited to, in any network or other electronic storage or transmission, or broadcast for distance learning.



一些辅助设备,包括电子和印刷组件,可能无法向美国以外的客户提供。

Some ancillaries, including electronic and print components, may not be available to customers outside the United States.



本书采用无酸纸印刷。

This book is printed on acid-free paper.



1 2 3 4 5 6 7 8 9 LCR 24 23 22 21 20 19

1 2 3 4 5 6 7 8 9 LCR 24 23 22 21 20 19



ISBN 978-1-260-54800-6(装订版)

ISBN 978-1-260-54800-6 (bound edition)

MHID 1-260-54800-7(装订版)

MHID 1-260-54800-7 (bound edition)



封面图片:© RL Hausdorf/Shutterstock

Cover Image: ©R.L. Hausdorf/Shutterstock











出现在书页或书末的所有出处均被视为版权页的延伸。

All credits appearing on page or at the end of the book are considered to be an extension of the copyright page.



文本中列出的互联网地址在发布时是准确的。包含网站并不表示作者或麦格劳-希尔教育的认可,并且麦格劳-希尔教育不保证这些网站上提供的信息的准确性。

The Internet addresses listed in the text were accurate at the time of publication. The inclusion of a website does not indicate an endorsement by the authors or McGraw-Hill Education, and McGraw-Hill Education does not guarantee the accuracy of the information presented at these sites.







mheducation.com/highered

mheducation.com/highered

第v页

Page v

致芭芭拉、马特、迈克、

希里、亚当、莉莉

和玛雅。

To Barbara, Matt, Mike,

Shiri, Adam, Lily,

and Maya.

—罗杰·S·普雷斯曼

—Roger S. Pressman





感谢我的家人,他们支持我所做的

一切。

To my family who

support me in all

that I do.

—布鲁斯·R·马克西姆

—Bruce R. Maxim

第六页

Page vi

关于作者_ _

About the Author

由罗杰·普莱斯曼提供

Courtesy of Roger Pressman

Roger S. Pressman是国际公认的软件工程顾问和作家。近五年来,他担任过软件工程师、经理、教授、作家、顾问和企业家。

Roger S. Pressman is an internationally recognized consultant and author in software engineering. For almost five decades, he has worked as a software engineer, a manager, a professor, an author, a consultant, and an entrepreneur.

Pressman 博士是 RS Pressman & Associates, Inc. 的总裁,该公司是一家专门帮助公司建立有效的软件工程策略的咨询公司。多年来,他开发了一套改进软件工程实践的技术和工具。他还是 EVANNEX ®的创始人兼首席技术官,EVANNEX ® 是一家汽车售后市场公司,专门为特斯拉电动汽车系列设计和制造配件。

Dr. Pressman was president of R. S. Pressman & Associates, Inc., a consulting firm that specialized in helping companies establish effective software engineering strategies. Over the years he developed a set of techniques and tools that improved software engineering practice. He is also the founder and chief technology officer of EVANNEX®, an automotive aftermarket company that specializes in the design and manufacture of accessories for the Tesla line of electric vehicles.

普雷斯曼博士是十本书的作者,其中包括两本小说以及许多技术和管理论文。他曾担任IEEE SoftwareThe Cutter IT Journal的编辑委员会成员,并且是IEEE Software的“Manager”专栏的编辑。

Dr. Pressman is the author of ten books, including two novels, and many technical and management papers. He has been on the editorial boards of IEEE Software and The Cutter IT Journal and was editor of the “Manager” column in IEEE Software.

Pressman 博士是一位著名的演讲者,曾在多个重大行业会议上发表过主题演讲。他曾在国际软件工程会议和许多其他行业会议上发表过教程。他是 ACM、IEEE、Tau Beta Pi、Phi Kappa Phi、Eta Kappa Nu 和 Pi Tau Sigma 的成员。

Dr. Pressman is a well-known speaker, keynoting a number of major industry conferences. He has presented tutorials at the International Conference on Software Engineering and at many other industry meetings. He has been a member of the ACM, IEEE, Tau Beta Pi, Phi Kappa Phi, Eta Kappa Nu, and Pi Tau Sigma.

密歇根创意/密歇根大学迪尔伯恩分校

Michigan Creative/UM-Dearborn

Bruce R. Maxim担任软件工程师、项目经理、教授、作家和顾问已有三十多年。他的研究兴趣包括软件工程、用户体验设计、严肃游戏开发、人工智能和工程教育。

Bruce R. Maxim has worked as a software engineer, project manager, professor, author, and consultant for more than thirty years. His research interests include software engineering, user experience design, serious game development, artificial intelligence, and engineering education.

Maxim 博士是密歇根大学迪尔伯恩分校计算机与信息科学教授和工程学院教授。他在工程与计算机科学学院建立了游戏实验室。他发表了有关计算机算法动画、游戏开发和工程教育的论文。他是一本畅销的计算机科学入门书籍和两本经过编辑的软件工程研究论文集的合著者。作为他在密歇根大学迪尔伯恩分校工作的一部分,Maxim 博士监督了数百个基于行业的软件开发项目。

Dr. Maxim is professor of computer and information science and collegiate professor of engineering at the University of Michigan–Dearborn. He established the GAME Lab in the College of Engineering and Computer Science. He has published papers on computer algorithm animation, game development, and engineering education. He is coauthor of a best-selling introductory computer science text and two edited collections of software engineering research papers. Dr. Maxim has supervised several hundred industry-based software development projects as part of his work at the University of Michigan–Dearborn.

Maxim 博士的专业经验包括管理医学院的研究信息系统、指导医学院的教学计算以及担任统计程序员。Maxim 博士曾担任一家游戏开发公司的首席技术官。

Dr. Maxim’s professional experience includes managing research information systems at a medical school, directing instructional computing for a medical campus, and working as a statistical programmer. Dr. Maxim served as the chief technology officer for a game development company.

马克西姆博士曾获得多项杰出教学奖、杰出社区服务奖和杰出教师管理奖。他是 Sigma Xi、Upsilon Pi Epsilon、Pi Mu Epsilon、计算机协会、IEEE 计算机协会、美国工程教育协会、女工程师协会和国际游戏开发者协会的成员。

Dr. Maxim was the recipient of several distinguished teaching awards, a distinguished community service award, and a distinguished faculty governance award. He is a member of Sigma Xi, Upsilon Pi Epsilon, Pi Mu Epsilon, Association of Computing Machinery, IEEE Computer Society, American Society for Engineering Education, Society of Women Engineers, and International Game Developers Association.

第七页

Page vii

内容一览_ _

Contents At a Glance

第一部分 软件流程 19

PART ONE THE SOFTWARE PROCESS 19

第二部分 建模 83

PART TWO MODELING 83

第三部分 质量和安全 309

PART THREE QUALITY AND SECURITY 309

第八页

Page viii

第四部分 管理软件项目 489

PART FOUR MANAGING SOFTWARE PROJECTS 489

第五部分 高级主题 567

PART FIVE ADVANCED TOPICS 567

第九页

Page ix

目录_ _ _

Table of Contents

前言二十七

Preface xxvii

第一章 软件和软件工程 1

Chapter 1 Software and Software Engineering 1

第一部分 软件流程 19

Part One The Software Process 19

第 2 章 流程模型 20

Chapter 2 Process Models 20

第 x 页

Page x

第 3 章 敏捷性和流程 37

Chapter 3 Agility and Process 37

第 4 章 推荐的流程模型 54

Chapter 4 Recommended Process Model 54

第 5 章 软件工程的人为因素 74

Chapter 5 Human Aspects of Software Engineering 74

第十一页

Page xi

第二部分 建模 83

Part Two Modeling 83

第六章 指导实践的原则84

Chapter 6 Principles That Guide Practice 84

第 7 章 了解要求 102

Chapter 7 Understanding Requirements 102

第十二页

Page xii

第 8 章 需求建模——推荐的方法 126

Chapter 8 Requirements Modeling—A Recommended Approach 126

第十三页

Page xiii

第9章 设计概念156

Chapter 9 Design Concepts 156

第10章 架构设计——推荐方法181

Chapter 10 Architectural Design—A Recommended Approach 181

第十四页

Page xiv

第11章 组件级设计206

Chapter 11 Component-Level Design 206

第十五页

Page xv

第12章 用户体验设计233

Chapter 12 User Experience Design 233

第 13 章 移动性设计 264

Chapter 13 Design for Mobility 264

第十六页

Page xvi

第14章 基于模式的设计289

Chapter 14 Pattern-Based Design 289

第三部分 质量和安全 309

Part Three Quality and Security 309

第15章 质量概念310

Chapter 15 Quality Concepts 310

第十七页

Page xvii

第 16 章 评论——推荐的方法 325

Chapter 16 Reviews—A Recommended Approach 325

第十七章 软件质量保证339

Chapter 17 Software Quality Assurance 339

第十八页

Page xviii

第18章 软件安全工程356

Chapter 18 Software Security Engineering 356

第十九页

Page xix

第 19 章 软件测试——组件级 372

Chapter 19 Software Testing—Component Level 372

第 20 章 软件测试——集成级别 395

Chapter 20 Software Testing—Integration Level 395

第xx页

Page xx

第 21 章 软件测试——移动专业测试 412

Chapter 21 Software Testing—Specialized TESTING for Mobility 412

第二十页

Page xxi

第22章 软件配置管理437

Chapter 22 Software Configuration Management 437

第23章 软件指标和分析460

Chapter 23 Software Metrics and Analytics 460

第二十二页

Page xxii

第四部分 管理软件项目 489

Part Four Managing Software Projects 489

第24章 项目管理概念490

Chapter 24 Project Management Concepts 490

第二十三页

Page xxiii

第25章 创建可行的软件计划504

Chapter 25 Creating a Viable Software Plan 504

第26章 风险管理532

Chapter 26 Risk Management 532

第二十四页

Page xxiv

第27章 软件支持策略549

Chapter 27 A Strategy for Software Support 549

第二十五页

Page xxv

第五部分 高级主题 567

Part Five Advanced Topics 567

第28章 软件过程改进568

Chapter 28 Software Process Improvement 568

第29章 软件工程的新兴趋势583

Chapter 29 Emerging Trends in Software Engineering 583

第二十六页

Page xxvi

第30章 结论602

Chapter 30 Concluding Comments 602

第二十七页

Page xxvii

前言_

Preface

当计算机软件成功时——当它满足使用它的人的需求时,当它在很长一段时间内完美地运行时,当它易于修改甚至更易于使用时——它可以而且确实使事情变得更好。但是,当软件出现故障时——当用户不满意、容易出错、难以更改甚至更难使用时——糟糕的事情就可能而且确实会发生。我们都希望构建能够让事情变得更好的软件,避免潜伏在失败努力阴影下的坏事情。为了取得成功,我们在设计和构建软件时需要遵守纪律。我们需要一种工程方法。

When computer software succeeds—when it meets the needs of the people who use it, when it performs flawlessly over a long period of time, when it is easy to modify and even easier to use—it can and does change things for the better. But when software fails—when its users are dissatisfied, when it is error prone, when it is difficult to change and even harder to use—bad things can and do happen. We all want to build software that makes things better, avoiding the bad things that lurk in the shadow of failed efforts. To succeed, we need discipline when software is designed and built. We need an engineering approach.

距离本书第一版的撰写已经过去近四十年了。在那段时间里,软件工程已经从一个由相对少数狂热者实践的晦涩想法发展成为一门合法的工程学科。今天,它被认为是一个值得认真研究、认真研究和激烈辩论的主题。在整个行业中,软件工程师已经取代程序员或编码员成为首选职位。软件过程模型、软件工程方法和软件工具已被广泛的行业领域成功采用。

It has been nearly four decades since the first edition of this book was written. During that time, software engineering has evolved from an obscure idea practiced by a relatively small number of zealots to a legitimate engineering discipline. Today, it is recognized as a subject worthy of serious research, conscientious study, and tumultuous debate. Throughout the industry, software engineer has replaced programmer or coder as the job title of preference. Software process models, software engineering methods, and software tools have been adopted successfully across a broad spectrum of industry segments.

尽管管理者和从业者都认识到需要对软件采取更加严格的方法,但他们仍在争论应用纪律的方式。许多个人和公司仍然随意开发软件,即使他们构建的系统是为当今最先进的技术服务的。许多专业人士和学生不了解现代方法。结果,我们生产的软件质量受到影响,并且发生了不好的事情。此外,关于软件工程方法的真正本质的争论和争议仍在继续。软件工程的现状是一项对比研究。人们的态度已经改变,取得了进步,但在该学科完全成熟之前还有很多工作要做。

Although managers and practitioners alike recognize the need for a more disciplined approach to software, they continue to debate the manner in which discipline is to be applied. Many individuals and companies still develop software haphazardly, even as they build systems to service today’s most advanced technologies. Many professionals and students are unaware of modern methods. And as a result, the quality of the software that we produce suffers, and bad things happen. In addition, debate, and controversy about the true nature of the software engineering approach continue. The status of software engineering is a study in contrasts. Attitudes have changed, progress has been made, but much remains to be done before the discipline reaches full maturity.

第九版新内容

New to the Ninth Edition

《软件工程:从业者的方法》第九版旨在作为成熟工程学科的指南。与之前的八版一样,第九版面向学生和从业者,保留了其作为行业专业人士指南的吸引力,以及对高年级本科生或研究生一年级学生的全面介绍。

The ninth edition of Software Engineering: A Practitioner’s Approach is intended to serve as a guide to a maturing engineering discipline. The ninth edition, like the eight editions that preceded it, is intended for both students and practitioners, retaining its appeal as a guide for the industry professional and a comprehensive introduction to the student at the upper-level undergraduate or first-year graduate level.

第二十八页第九版不仅仅是一个简单的更新。本书经过修订和重组,以改进教学流程并强调新的重要的软件工程过程和实践。此外,我们还进一步增强了本书广受欢迎的“支持系统”,提供了一套全面的学生、教师和专业资源来补充本书的内容。

Page xxviiiThe ninth edition is considerably more than a simple update. The book has been revised and restructured to improve pedagogical flow and emphasize new and important software engineering processes and practices. In addition, we have further enhanced the popular “support system” for the book, providing a comprehensive set of student, instructor, and professional resources to complement the content of the book.

读过过去几版《软件工程:从业者的方法》的读者会注意到,第九版的页长实际上有所减少。我们的目标是简洁,从教学的角度使这本书变得更强大,并且让那些想要读完整本书的读者不那么畏惧。著名数学家和物理学家布莱斯·帕斯卡(Blaise Pascal)有这样一个轶事:在给朋友写一封过长的信时,帕斯卡以这句话结尾。“我想给你写封短一点的信,但我没有时间。” 当我们致力于第九版的简洁时,我们开始欣赏帕斯卡的话。

Readers of the past few editions of Software Engineering: A Practitioner’s Approach will note that the ninth edition has actually been reduced in page length. Our goal was concision, making the book stronger from a pedagogical viewpoint and less daunting for the reader who desires to journey through the entire book. An anecdote, attributed to Blaise Pascal, the famous mathematician and physicist, goes like this: In writing a overly long letter to a friend, Pascal ended with this sentence. “I wanted to write you a shorter letter, but I didn’t have the time.” As we worked on concision for the ninth edition, we came to appreciate Pascal’s words.

第九版共30章,分为五个部分。该组织可以更好地划分主题,并为可能没有时间在一个学期内完成整本书的教师提供帮助。

The 30 chapters of the ninth edition are organized into five parts. This organization better compartmentalizes topics and assists instructors who may not have the time to complete the entire book in one term.

第 1 部分“软件过程”提出了软件过程的各种不同观点,考虑了几个重要的过程模型和框架,使我们能够解决规范性过程哲学和敏捷过程哲学之间的争论。第 2 部分“建模”介绍了分析和设计方法,重点是面向对象技术和 UML 建模。还考虑了基于模式的设计和移动计算应用程序的设计。本节扩大了用户体验设计的覆盖范围。第 3 部分,质量和安全,介绍了使软件团队能够评估软件质量、审查软件工程工作产品、执行 SQA 程序以及应用有效的测试策略和策略的概念、过程、技术和方法。此外,我们还提出了可以插入增量软件开发模型的软件安全实践。第 4 部分“管理软件项目”介绍与规划、管理和控制软件开发项目的人员相关的主题。第 5 部分,高级主题,考虑软件过程改进和软件工程趋势。整本书都包含盒装功能,以展示(虚构的)软件团队的考验和磨难,并提供与章节主题相关的方法和工具的补充材料。

Part 1, The Software Process, presents a variety of different views of software process, considering several important process models and frameworks that allow us to address the debate between prescriptive and agile process philosophies. Part 2, Modeling, presents analysis and design methods with an emphasis on object-oriented techniques and UML modeling. Pattern-based design and design for mobility computing applications are also considered. The coverage of user experience design has been expanded in this section. Part 3, Quality and Security, presents the concepts, procedures, techniques, and methods that enable a software team to assess software quality, review software engineering work products, conduct SQA procedures, and apply an effective testing strategy and tactics. In addition, we present software security practices that can be inserted into incremental software development models. Part 4, Managing Software Projects, presents topics that are relevant to those who plan, manage, and control a software development project. Part 5, Advanced Topics, considers software process improvement and software engineering trends. Boxed features are included throughout the book to present the trials and tribulations of a (fictional) software team and to provide supplementary materials about methods and tools that are relevant to chapter topics.

第九版的五部分组织使教师能够根据可用时间和学生需求对主题进行“聚类”。整个一学期的课程可以围绕五个部分中的一个或多个部分构建。软件工程调查课程将从所有五个部分中选择章节。强调分析和设计的软件工程课程将从第 1 部分和第 2 部分中选择主题。面向测试的软件工程课程将从第 1 部分和第 3 部分中选择主题,并简要介绍第 2 部分。“管理课程”将强调第 1 部分和第 2 部分。 1 和 4。通过以这种方式组织第九版,我们试图为教师提供多种教学选择。在每种情况下,第九版的内容均由SEPA、9/e 支持系统的以下要素进行补充。第xxxx页

The five-part organization of the ninth edition enables an instructor to “cluster” topics based on available time and student need. An entire one-term course can be built around one or more of the five parts. A software engineering survey course would select chapters from all five parts. A software engineering course that emphasizes analysis and design would select topics from Parts 1 and 2. A testing-oriented software engineering course would select topics from Parts 1 and 3, with a brief foray into Part 2. A “management course” would stress Parts 1 and 4. By organizing the ninth edition in this way, we have attempted to provide an instructor with a number of teaching options. In every case the content of the ninth edition is complemented by the following elements of the SEPA, 9/e Support System.Page xxix

其他资源

Additional Resources

可以通过讲师网站访问各种资源,包括包含问题解决方案的广泛在线学习中心、带有软件工程清单的各种基于网络的资源、不断发展的“微型工具”集合以及全面的案例研究。专业资源提供数百个分类的网络参考,使学生能够更详细地探索软件工程,以及参考库包含数百个可下载参考资料的链接,提供高级软件工程信息的深入来源。此外,还包括完整的在线教师指南和补充教材以及数百张可用于讲座的 PowerPoint 幻灯片。

A wide variety of resources can be accessed through the instructor website, including an extensive online learning center encompassing problem solutions, a variety of Web-based resources with software engineering checklists, an evolving collection of “tiny tools,” and comprehensive case studies. Professional Resources provide several hundred categorized web references which allow students to explore software engineering in greater detail, along with a reference library with links to several hundred downloadable references providing an in-depth source of advanced software engineering information. Additionally, a complete online Instructor’s Guide and supplementary teaching materials along with several hundred PowerPoint slides that may be used for lectures are included.

软件工程教师指南:从业者的方法》提出了开展各种类型的软件工程课程的建议、与课程结合进行的各种软件项目的建议、选定问题的解决方案以及许多有用的教学辅助工具。

The Instructor’s Guide for Software Engineering: A Practitioner’s Approach presents suggestions for conducting various types of software engineering courses, recommendations for a variety of software projects to be conducted in conjunction with a course, solutions to selected problems, and a number of useful teaching aids.

与其在线支持系统相结合, 《软件工程:从业者的方法》第九版提供了仅靠教科书无法实现的灵活性和内容深度。

When coupled with its online support system, the ninth edition of Software Engineering: A Practitioner’s Approach provides flexibility and depth of content that cannot be achieved by a textbook alone.

Bruce Maxim 牵头为《软件工程:从业者的方法》第九版开发新内容,而 Roger Pressman 担任主编并在特定情况下提供贡献。

Bruce Maxim has taken the lead in developing new content for the ninth edition of Software Engineering: A Practitioner’s Approach, while Roger Pressman has served as editor-in-chief as well as providing contributions in select circumstances.

致谢特别感谢卡内基梅隆大学软件工程学院的 Nancy Mead,她撰写了有关软件安全工程的章节;渥太华大学的 Tim Lethbridge 帮助我们开发 UML 和 OCL 示例,并开发了本书随附的案例研究;科尔比学院 (Colby College) 的 Dale Skrien 开发了附录 1 中的 UML 教程;密歇根大学迪尔伯恩分校的 William Grosky 与他的学生 Terry Ruas 在附录 2 中概述了数据科学;以及我们的澳大利亚同事 Margaret Kellow 更新了本书附带的教学网络材料。此外,我们还要感谢 Austin Krauss 从高级软件工程师的角度提供了对视频游戏行业软件开发的见解。

Acknowledgments Special thanks go to Nancy Mead from Software Engineering Institute at Carnegie Mellon University who wrote the chapter on software security engineering; Tim Lethbridge of the University of Ottawa who assisted us in the development of UML and OCL examples and developed the case study that accompanies this book; Dale Skrien of Colby College who developed the UML tutorial in Appendix 1; William Grosky of the University of Michigan–Dearborn who developed the overview of data science in Appendix 2 with his student Terry Ruas; and our Australian colleague Margaret Kellow for updating the pedagogical Web materials that accompany this book. In addition, we would like to thank Austin Krauss for providing insight into software development in the video game industry from his perspective as a senior software engineer.

特别感谢BRM:我很高兴有机会与罗杰合作编写本书的第九版。在我撰写本书期间,我的儿子本杰明已成为一名软件工程经理,我的女儿凯瑟琳则利用她的艺术背景创作了本书章节中出现的人物。我很高兴看到他们已经成为成年人,并享受与他们的孩子(艾拉、艾玛和塞尔玛)在一起的时光。我非常感谢我的妻子诺玛,她在我利用空闲时间写这本书时给予了我热情的支持。

Special Thanks BRM: I am grateful to have had the opportunity to work with Roger on the ninth edition of this book. During the time I have been working on this book, my son, Benjamin, has become a software engineering manager and my daughter, Katherine, used her art background to create the figures that appear in the book chapters. I am quite pleased to see the adults they have become and enjoy my time with their children (Isla, Emma, and Thelma). I am very grateful to my wife, Norma, for her enthusiastic support as I filled my free time working on this book.

第xxx页RSP:随着本书版本的演变,我的儿子马修和迈克尔已经从男孩成长为男人。他们的成熟、性格和在现实世界中的成功给了我很大的启发。在遵循自己的职业道路多年之后,我们三人现在在 2012 年创立的一家企业中共同工作。没有什么比这更让我感到自豪的了。我的两个儿子现在都有了自己的孩子,玛雅和莉莉,他们又开始了新的一代。最后,向我的妻子芭芭拉表达我的爱和感谢,感谢她在办公室里忍受了很多很多时间,并鼓励了“这本书”的另一版。

Page xxxRSP: As the editions of this book have evolved, my sons, Mathew and Michael, have grown from boys to men. Their maturity, character, and success in the real world have been an inspiration to me. After many years of following our own professional paths, the three of us now work together in a business that we founded in 2012. Nothing has filled me with more pride. Both of my sons now have children of their own, Maya and Lily, who start still another generation. Finally, to my wife, Barbara, my love and thanks for tolerating the many, many hours in the office and encouraging still another edition of “the book.”

布鲁斯·R·马克西姆

Bruce R. Maxim

罗杰·S·普雷斯曼

Roger S. Pressman

第xxxi页

Page xxxi

第1页

Page 1

章节

chapter

1软件与软件工程

1 Software and Software Engineering

当他向我展示了世界上最受欢迎的第一人称射击游戏之一的最新版本时,这位年轻的开发者笑了。

As he finished showing me the latest build of one of the world’s most popular first-person shooter video games, the young developer laughed.

“你不是游戏玩家,是吗?” 他问。

“You’re not a gamer, are you?” he asked.

我笑了。“你怎么猜到的?”

I smiled. “How’d you guess?”

这个年轻人穿着短裤和T恤。他的腿像活塞一样上下弹跳,燃烧着同事们似乎司空见惯的紧张能量。

The young man was dressed in shorts and a tee shirt. His leg bounced up and down like a piston, burning the nervous energy that seemed to be commonplace among his co-workers.

第2页“因为如果你是,”他说,“你会更加兴奋。您已经看到了我们的下一代产品,这是我们的客户会渴望的东西。。。没有双关语的意思。”

Page 2“Because if you were,” he said, “you’d be a lot more excited. You’ve gotten a peek at our next generation product and that’s something that our customers would kill for . . . no pun intended.”

我们坐在地球上最成功的游戏开发商之一的开发区。多年来,他演示的前几代游戏销量超过 5000 万份,创造了数十亿美元的收入。

We sat in a development area at one of the most successful game developers on the planet. Over the years, earlier generations of the game he demoed sold over 50 million copies and generated billions of dollars in revenue.

“那么,这个版本什么时候上市?” 我问。

“So, when will this version be on the market?” I asked.

他耸耸肩。“大约五个月后,我们还有很多工作要做。”

He shrugged. “In about five months, and we’ve still got a lot of work to do.”

他负责一个包含超过三百万行代码的应用程序中的游戏玩法和人工智能功能。

He had responsibility for game play and artificial intelligence functionality in an application that encompassed more than three million lines of code.

“你们使用任何软件工程技术吗?” 我问道,半期待着他会笑着摇摇头。

“Do you guys use any software engineering techniques?” I asked, half-expecting that he’d laugh and shake his head.

他停下来想了一会儿。然后他缓缓地点了点头。“我们会根据我们的需求调整它们,但当然,我们会使用它们。”

He paused and thought for a moment. Then he slowly nodded. “We adapt them to our needs, but sure, we use them.”

“在哪里?” 我试探着问道。

“Where?” I asked, probing.

“我们的问题通常是如何转化创意人员提出的要求。”

“Our problem is often translating the requirements the creatives give us.”

“创意?” 我打断道。

“The creatives?” I interrupted.

“你知道,那些设计故事、角色以及所有让游戏大受欢迎的东西的人。我们必须接受他们给我们的东西,并制定一套技术要求,使我们能够构建游戏。”

“You know, the guys who design the story, the characters, all the stuff that make the game a hit. We have to take what they give us and produce a set of technical requirements that allow us to build the game.”

“那么在要求确定之后呢?”

“And after the requirements are established?”

他耸耸肩。“我们必须扩展和调整前一版本游戏的架构并创建新产品。我们必须根据需求创建代码,通过日常构建测试代码,并执行您书中推荐的许多事情。”

He shrugged. “We have to extend and adapt the architecture of the previous version of the game and create a new product. We have to create code from the requirements, test the code with daily builds, and do lots of things that your book recommends.”

“你知道我的书吗?” 老实说我很惊讶。

“You know my book?” I was honestly surprised.

“当然,在学校用过它。那里有很多东西。”

“Sure, used it in school. There’s a lot there.”

“我和你这里的一些朋友谈过,他们对我书中的内容更加持怀疑态度。”

“I’ve talked to some of your buddies here, and they’re more skeptical about the stuff in my book.”

他皱起了眉头。“看,我们不是 IT 部门或航空航天公司,所以我们必须定制您所提倡的内容。但底线是一样的——我们需要生产高质量的产品,而我们能够以可重复的方式实现这一目标的唯一方法就是适应我们自己的软件工程技术子集。”

He frowned. “Look, we’re not an IT department or an aerospace company, so we have to customize what you advocate. But the bottom line is the same—we need to produce a high-quality product, and the only way we can accomplish that in a repeatable fashion is to adapt our own subset of software engineering techniques.”

“随着时间的推移,你的子集会发生怎样的变化?”

“And how will your subset change as the years pass?”

他停了下来,仿佛在思考未来。“游戏将会变得更大、更复杂,这是肯定的。随着更多竞争的出现,我们的开发时间将会缩短。慢慢地,游戏本身将迫使我们应用更多的开发纪律。如果我们不这样做,我们就死定了。”

He paused as if to ponder the future. “Games will become bigger and more complex, that’s for sure. And our development timelines will shrink as more competition emerges. Slowly, the games themselves will force us to apply a bit more development discipline. If we don’t, we’re dead.”

*****

*****

计算机软件仍然是世界舞台上最重要的技术。这也是意外后果定律的一个典型例子。六十年前,没有人能够预见到软件会成为商业、科学和工程不可或缺的技术;现在,软件已经成为商业、科学和工程领域不可或缺的技术。该软件将能够创造新技术(例如基因工程和纳米技术)、扩展现有技术(例如电信)以及彻底改变旧技术(例如媒体);该软件将成为个人计算机革命背后的驱动力;消费者将使用其移动设备购买软件应用程序;随着“按需”软件公司通过网络浏览器提供即时功能,该软件将从产品慢慢演变为服务;软件公司将比所有工业时代的公司变得更大、更有影响力;或者一个庞大的软件驱动网络将发展并改变一切,从图书馆研究到消费者购物,从政治话语到年轻人(而不是那么年轻)的约会习惯。第3页

Computer software continues to be the single most important technology on the world stage. And it’s also a prime example of the law of unintended consequences. Sixty years ago no one could have predicted that software would become an indispensable technology for business, science, and engineering; that software would enable the creation of new technologies (e.g., genetic engineering and nanotechnology), the extension of existing technologies (e.g., telecommunications), and the radical change in older technologies (e.g., the media); that software would be the driving force behind the personal computer revolution; that software applications would be purchased by consumers using their mobile devices; that software would slowly evolve from a product to a service as “on-demand” software companies deliver just-in-time functionality via a Web browser; that a software company would become larger and more influential than all industrial-era companies; or that a vast software-driven network would evolve and change everything from library research to consumer shopping to political discourse to the dating habits of young (and not so young) adults.Page 3

随着软件重要性的不断增长,软件社区不断尝试开发技术,使构建和支持高质量计算机程序变得更容易、更快、更便宜。其中一些技术针对特定应用领域(例如网站设计和实现);其他人专注于技术领域(例如,面向对象的系统或面向方面的编程);还有一些具有广泛的基础(例如,Linux 等操作系统)。然而,我们还没有开发出一种能够完成这一切的软件技术,而且未来出现这种技术的可能性很小。然而,人们却把自己的工作、舒适、安全、娱乐、决定以及生命都押在了计算机软件上。最好是对的。

As software’s importance has grown, the software community has continually attempted to develop technologies that will make it easier, faster, and less expensive to build and support high-quality computer programs. Some of these technologies are targeted at a specific application domain (e.g., website design and implementation); others focus on a technology domain (e.g., object-oriented systems or aspect-oriented programming); and still others are broad based (e.g., operating systems such as Linux). However, we have yet to develop a software technology that does it all, and the likelihood of one arising in the future is small. And yet, people bet their jobs, their comforts, their safety, their entertainment, their decisions, and their very lives on computer software. It better be right.

本书提出了一个可供那些构建计算机软件的人(必须正确使用它的人)使用的框架。该框架包含一个流程、一组方法和一系列我们称之为软件工程的工具。

This book presents a framework that can be used by those who build computer software—people who must get it right. The framework encompasses a process, a set of methods, and an array of tools that we call software engineering.

要构建能够应对二十一世纪挑战的软件,您必须认识到一些简单的现实:

To build software that is ready to meet the challenges of the twenty-first century, you must recognize a few simple realities:

  • 软件几乎已经深深嵌入我们生活的方方面面。对特定应用程序1提供的特性和功能感兴趣的人数急剧增加。在开发软件解决方案之前,应共同努力理解问题。

  • Software has become deeply embedded in virtually every aspect of our lives. The number of people who have an interest in the features and functions provided by a specific application1 has grown dramatically. A concerted effort should be made to understand the problem before a software solution is developed.

  • 个人、企业和政府对信息技术的要求逐年变得越来越复杂。现在,大型团队创建计算机程序。曾经在可预测的独立计算环境中实现的复杂软件现在已嵌入到从消费电子产品到医疗设备再到自动驾驶汽车的所有内容中。设计已成为一项关键活动。

  • The information technology requirements demanded by individuals, businesses, and governments grow increasingly complex with each passing year. Large teams of people now create computer programs. Sophisticated software that was once implemented in a predictable, self-contained computing environment is now embedded inside everything from consumer electronics to medical devices to autonomous vehicles. Design has become a pivotal activity.

  • 个人、企业和政府越来越依赖软件进行战略和战术决策以及日常运营和控制。如果软件出现故障,人们和大型企业可能会遇到从轻微的不便到灾难性的后果。软件应该表现出高质量。

  • Individuals, businesses, and governments increasingly rely on software for strategic and tactical decision making as well as day-to-day operations and control. If the software fails, people and major enterprises can experience anything from minor inconvenience to catastrophic consequences. Software should exhibit high quality.

  • 随着特定应用程序的感知价值不断增长,其用户群和寿命也可能会增长。随着其用户群和使用时间的增加,适配和增强的需求也会增长。软件应该是可维护的。

  • As the perceived value of a specific application grows, the likelihood is that its user base and longevity will also grow. As its user base and time in use increase, demands for adaptation and enhancement will also grow. Software should be maintainable.

这些简单的现实引出了一个结论:所有形式和跨所有应用领域的软件都应该被设计。这就引出了本书的主题——软件工程。

These simple realities lead to one conclusion: Software in all its forms and across all its application domains should be engineered. And that leads us to the topic of this book—software engineering.

第4页

Page 4

1.1 软件的本质

1.1 The Nature of Software

如今,软件扮演着双重角色。它是一种产品,也是交付产品的工具。作为一种产品,它提供了由计算机硬件或更广泛地由本地硬件可访问的计算机网络体现的计算潜力。无论是驻留在移动设备、桌面、云中,还是大型计算机或自主机器中,软件都是信息转换器——生成、管理、获取、修改、显示或传输信息,这些信息可以像单个位或像增强现实表示一样复杂,该表示源自从数十个独立来源获取的数据,然后叠加在现实世界上。作为用于交付产品的工具,软件是计算机控制(操作系统)、信息通信(网络)以及其他程序(软件工具和环境)创建和控制的基础。

Today, software takes on a dual role. It is a product, and the vehicle for delivering a product. As a product, it delivers the computing potential embodied by computer hardware or, more broadly, by a network of computers that are accessible by local hardware. Whether it resides within a mobile device, on the desktop, in the cloud, or within a mainframe computer or autonomous machine, software is an information transformer—producing, managing, acquiring, modifying, displaying, or transmitting information that can be as simple as a single bit or as complex as an augmented-reality representation derived from data acquired from dozens of independent sources and then overlaid on the real world. As the vehicle used to deliver a product, software acts as the basis for the control of the computer (operating systems), the communication of information (networks), and the creation and control of other programs (software tools and environments).

软件提供了我们这个时代最重要的产品——信息。它转换个人数据(例如个人的金融交易),以便数据在本地环境中更有用;管理商业信息以提高竞争力;它提供了通往全球信息网络(例如互联网)的门户;并提供获取各种形式信息的手段。它还提供了一个可能威胁个人隐私的工具,以及一个使恶意者能够实施犯罪行为的网关。

Software delivers the most important product of our time—information. It transforms personal data (e.g., an individual’s financial transactions) so that the data can be more useful in a local context; it manages business information to enhance competitiveness; it provides a gateway to worldwide information networks (e.g., the Internet); and provides the means for acquiring information in all its forms. It also provides a vehicle that can threaten personal privacy and a gateway that enables those with malicious intent to commit criminal acts.

过去 60 年来,计算机软件的作用发生了重大变化。硬件性能的显着提高、计算架构的深刻变化、内存和存储容量的大幅增加以及各种奇特的输入和输出选项都催生了更加复杂的基于计算机的系统。当系统成功时,复杂性可以产生令人眼花缭乱的结果,但它们也可能给那些必须构建和保护复杂系统的人带来巨大的问题。

The role of computer software has undergone significant change over the last 60 years. Dramatic improvements in hardware performance, profound changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. Sophistication and complexity can produce dazzling results when a system succeeds, but they can also pose huge problems for those who must build and protect complex systems.

如今,庞大的软件产业已成为工业化世界经济的主导因素。由软件专家组成的团队,每个人都专注于交付复杂应用程序所需的技术的一部分,已经取代了早期时代的孤独程序员。然而,向孤独的程序员提出的问题与构建现代基于计算机的系统时提出的问题是相同的:2

Today, a huge software industry has become a dominant factor in the economies of the industrialized world. Teams of software specialists, each focusing on one part of the technology required to deliver a complex application, have replaced the lone programmer of an earlier era. And yet, the questions that were asked of the lone programmer are the same questions that are asked when modern computer-based systems are built:2

  • 为什么软件需要这么长时间才能完成?

  • Why does it take so long to get software finished?

  • 为何开发成本如此之高?

  • Why are development costs so high?

  • 为什么我们在将软件提供给客户之前无法找到所有错误?

  • Why can’t we find all errors before we give the software to our customers?

  • 为什么我们要花费如此多的时间和精力来维护现有的程序?

  • Why do we spend so much time and effort maintaining existing programs?

  • 为什么我们在软件开发和维护过程中仍然难以衡量进度?

  • Why do we continue to have difficulty in measuring progress as software is being developed and maintained?

第5页这些问题以及许多其他问题都是对软件及其开发方式的关注的体现,这种关注导致了软件工程实践的采用。

Page 5These, and many other questions, are a manifestation of the concern about software and how it is developed—a concern that has led to the adoption of software engineering practice.

1.1.1 定义软件

1.1.1 Defining Software

如今,大多数专业人士和许多公众都认为他们了解软件。但他们真的吗?

Today, most professionals and many members of the public at large feel that they understand software. But do they?

软件的教科书描述可能采用以下形式:

A textbook description of software might take the following form:

软件是: (1) 执行时提供所需特征、功能和性能的指令(计算机程序);(2) 使程序能够充分操纵信息的数据结构;(3) 描述程序操作和使用的硬拷贝和虚拟形式的描述性信息。

Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information; and (3) descriptive information in both hard copy and virtual forms that describes the operation and use of the programs.

毫无疑问可以提供其他更完整的定义。但更正式的定义可能不会显着提高您的理解。为了实现这一目标,重要的是要检查软件的特征,这些特征使其不同于人类构建的其他东西。软件是逻辑系统元素,而不是物理系统元素。因此,软件有一个与硬件显着不同的基本特征:软件不会“磨损”。

There is no question that other more complete definitions could be offered. But a more formal definition probably won’t measurably improve your understanding. To accomplish that, it’s important to examine the characteristics of software that make it different from other things that human beings build. Software is a logical rather than a physical system element. Therefore, software has one fundamental characteristic that makes it considerably different from hardware: Software doesn’t “wear out.”

图 1.1将硬件故障率描述为时间的函数。这种关系通常被称为“浴缸曲线”,表明硬件在其生命早期表现出相对较高的故障率(这些故障通常归因于设计或制造缺陷);缺陷得到纠正,并且故障率在一段时间内下降到稳态水平(希望非常低)。然而,随着时间的推移,由于硬件组件受到灰尘、振动、滥用、极端温度和许多其他环境问题的累积影响,故障率再次上升。简而言之,硬件开始磨损。

Figure 1.1 depicts failure rate as a function of time for hardware. The relationship, often called the “bathtub curve,” indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected, and the failure rate drops to a steady-state level (hopefully, quite low) for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies. Stated simply, the hardware begins to wear out.

1.1 硬件故障曲线

Figure 1.1 Failure curve for hardware

第6页软件不易受到导致硬件磨损的环境问题的影响。因此,从理论上讲,软件的故障率曲线应该采用图1.2所示的“理想化曲线”的形式。未被发现的缺陷将导致程序生命周期早期的高失败率。然而,这些已得到纠正,并且曲线变平,如图所示。理想化曲线是对软件实际故障模型的过度简化。然而,含义很明确——软件不会磨损。但确实会恶化!

Page 6Software is not susceptible to the environmental maladies that cause hardware to wear out. In theory, therefore, the failure rate curve for software should take the form of the “idealized curve” shown in Figure 1.2. Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected and the curve flattens as shown. The idealized curve is a gross oversimplification of actual failure models for software. However, the implication is clear—software doesn’t wear out. But it does deteriorate!

1.2 软件故障曲线

Figure 1.2 Failure curves for software

这种看似矛盾的现象最好通过考虑图 1.2中的实际曲线来解释。在其生命周期中,有 3 个软件会发生变化。当进行更改时,很可能会引入错误,导致故障率曲线出现峰值,如“实际曲线”所示(图1.2)。在曲线返回到原始稳态故障率之前,需要进行另一次更改,导致曲线再次尖峰。慢慢地,最低故障率水平开始上升——软件由于变化而恶化。

This seeming contradiction can best be explained by considering the actual curve in Figure 1.2. During its life,3 software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike as shown in the “actual curve” (Figure 1.2). Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to rise—the software is deteriorating due to change.

磨损的另一个方面说明了硬件和软件之间的差异。当硬件组件磨损时,会用备件进行更换。没有软件备件。每个软件故障都表明设计中或将设计转换为机器可执行代码的过程中存在错误。因此,适应变更请求的软件维护任务比硬件维护复杂得多。

Another aspect of wear illustrates the difference between hardware and software. When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, the software maintenance tasks that accommodate requests for change involve considerably more complexity than hardware maintenance.

第7页

Page 7

1.1.2 软件应用领域

1.1.2 Software Application Domains

如今,七大类计算机软件给软件工程师带来了持续的挑战:

Today, seven broad categories of computer software present continuing challenges for software engineers:

系统软件。为服务其他程序而编写的程序的集合。一些系统软件(例如,编译器、编辑器和文件管理实用程序)处理复杂但确定的4 种信息结构。其他系统应用程序(例如操作系统组件、驱动程序、网络软件、电信处理器)主要处理不确定的数据。

System software. A collection of programs written to service other programs. Some system software (e.g., compilers, editors, and file management utilities) processes complex, but determinate,4 information structures. Other systems applications (e.g., operating system components, drivers, networking software, telecommunications processors) process largely indeterminate data.

应用程序软件。解决特定业务需求的独立程序。该领域的应用程序以促进业务运营或管理/技术决策的方式处理业务或技术数据。

Application software. Stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making.

工程/科学软件。一系列广泛的“数字运算”或数据科学项目,范围从天文学到火山学,从汽车应力分析到轨道动力学,从计算机辅助设计到消费者消费习惯,从基因分析到气象学。

Engineering/scientific software. A broad array of “number-crunching” or data science programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, from computer-aided design to consumer spending habits, and from genetic analysis to meteorology.

嵌入式软件。驻留在产品或系统中,用于为最终用户和系统本身实现和控制特性和功能。嵌入式软件可以执行有限且深奥的功能(例如,微波炉的键盘控制)或提供重要的功能和控制能力(例如,汽车中的数字功能,例如燃油控制、仪表板显示和制动系统)。

Embedded software. Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Embedded software can perform limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).

产品线软件。由可重复使用的组件组成,旨在提供特定功能供许多不同的客户使用。它可能专注于有限且深奥的市场(例如,库存控制产品)或尝试解决大众消费者市场。

Product-line software. Composed of reusable components and designed to provide specific capabilities for use by many different customers. It may focus on a limited and esoteric marketplace (e.g., inventory control products) or attempt to address the mass consumer market.

网络/移动应用程序。这种以网络为中心的软件类别涵盖广泛的应用程序,包括基于浏览器的应用程序、云计算、基于服务的计算以及驻留在移动设备上的软件。

Web/mobile applications. This network-centric software category spans a wide array of applications and encompasses browser-based apps, cloud computing, service-based computing, and software that resides on mobile devices.

人工智能软件。利用启发式5来解决无法进行常规计算或直接分析的复杂问题。该领域的应用包括机器人、决策系统、模式识别(图像和语音)、机器学习、定理证明和游戏。

Artificial intelligence software. Makes use of heuristics5 to solve complex problems that are not amenable to regular computation or straightforward analysis. Applications within this area include robotics, decision-making systems, pattern recognition (image and voice), machine learning, theorem proving, and game playing.

全球数以百万计的软件工程师正在努力从事其中一个或多个类别的软件项目。在某些情况下,正在构建新系统,但在许多其他情况下,现有应用程序正在得到纠正、调整和增​​强。年轻的软件工程师开发比她年龄还大的程序并不罕见!过去几代软件人在我们讨论的每个类别中都留下了遗产。希望这一代人留下的遗产能够减轻未来软件工程师的负担。

Millions of software engineers worldwide are hard at work on software projects in one or more of these categories. In some cases, new systems are being built, but in many others, existing applications are being corrected, adapted, and enhanced. It is not uncommon for a young software engineer to work on a program that is older than she is! Past generations of software people have left a legacy in each of the categories we have discussed. Hopefully, the legacy to be left behind by this generation will ease the burden on future software engineers.

第8页

Page 8

1.1.3 遗留软件

1.1.3 Legacy Software

数十万个计算机程序属于上一小节讨论的七个广泛应用领域之一。其中一些是最先进的软件。但其他程序更老,在某些情况下老。

Hundreds of thousands of computer programs fall into one of the seven broad application domains discussed in the preceding subsection. Some of these are state-of-the-art software. But other programs are older, in some cases much older.

这些较旧的程序(通常称为遗留软件)自 20 世纪 60 年代以来一直是人们持续关注和关注的焦点。Dayani-Fard 和他的同事 [Day99] 用以下方式描述遗留软件:

These older programs—often referred to as legacy software—have been the focus of continuous attention and concern since the 1960s. Dayani-Fard and his colleagues [Day99] describe legacy software in the following way:

遗留软件系统。。。它们是几十年前开发的,并不断进行修改以满足业务需求和计算平台的变化。此类系统的激增给大型组织带来了麻烦,他们发现这些系统的维护成本高昂且发展存在风险。

Legacy software systems . . . were developed decades ago and have been continually modified to meet changes in business requirements and computing platforms. The proliferation of such systems is causing headaches for large organizations who find them costly to maintain and risky to evolve.

这些更改可能会产生传统软件中经常出现的额外副作用——质量差6遗留系统有时具有不可扩展的设计、复杂的代码、糟糕或不存在的文档、从未存档的测试用例和结果以及管理不善的变更历史记录。这个列表可能很长。然而,这些系统通常支持“核心功能,并且对业务来说是不可或缺的”。该怎么办?

These changes may create an additional side effect that is often present in legacy software—poor quality.6 Legacy systems sometimes have inextensible designs, convoluted code, poor or nonexistent documentation, test cases and results that were never archived, and a poorly managed change history. The list can be quite long. And yet, these systems often support “core functions and are indispensable to the business.” What to do?

唯一合理的答案可能是:什么也不做,至少在遗留系统必须经历一些重大改变之前。如果遗留软件能够满足用户的需求并且运行可靠,那么它就没有损坏,也不需要修复。然而,随着时间的推移,遗留系统通常会因以下一个或多个原因而演变:

The only reasonable answer may be: Do nothing, at least until the legacy system must undergo some significant change. If the legacy software meets the needs of its users and runs reliably, it isn’t broken and does not need to be fixed. However, as time passes, legacy systems often evolve for one or more of the following reasons:

  • 软件必须进行调整以满足新计算环境或技术的需求。

  • The software must be adapted to meet the needs of new computing environments or technology.

  • 必须增强软件才能满足新的业务需求。

  • The software must be enhanced to implement new business requirements.

  • 该软件必须进行扩展,才能与其他更现代的系统或数据库一起使用。

  • The software must be extended to make it work with other more modern systems or databases.

  • 该软件必须重新架构,以使其在不断发展的计算环境中可行。

  • The software must be re-architected to make it viable within an evolving computing environment.

当这些演变模式发生时,必须重新设计遗留系统,使其在未来仍然可行。现代软件工程的目标是“设计基于进化概念的方法;也就是说,软件系统不断变化,新的软件系统可以从旧的软件系统中构建出来,并且。。。所有人都必须相互互动和合作”[Day99]。

When these modes of evolution occur, a legacy system must be reengineered so that it remains viable in the future. The goal of modern software engineering is to “devise methodologies that are founded on the notion of evolution; that is, the notion that software systems change continually, new software systems can be built from the old ones, and . . . all must interact and cooperate with each other” [Day99].

1.2 学科定义

1.2 Defining the Discipline

IEEE [IEE17] 为软件工程制定了以下定义:

The IEEE [IEE17] has developed the following definition for software engineering:

软件工程:应用系统的、规范的、可量化的方法来开发、操作和维护软件;即工程在软件上的应用。

Software Engineering: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

第9页然而,一个软件团队采用的“系统性、规范性和可量化”方法可能会给另一个软件团队带来负担。我们需要纪律,但我们也需要适应性和敏捷性。

Page 9And yet, a “systematic, disciplined, and quantifiable” approach applied by one software team may be burdensome to another. We need discipline, but we also need adaptability and agility.

软件工程是一种分层技术。参考图 1.3,任何工程方法(包括软件工程)都必须依赖于组织对质量的承诺。您可能听说过全面质量管理 (TQM) 或六西格码,以及类似的理念7,它们培养了持续流程改进的文化。正是这种文化最终带来了更有效的软件工程方法。支持软件工程的基石是质量焦点。

Software engineering is a layered technology. Referring to Figure 1.3, any engineering approach (including software engineering) must rest on an organizational commitment to quality. You may have heard of total quality management (TQM) or Six Sigma, and similar philosophies7 that foster a culture of continuous process improvement. It is this culture that ultimately leads to more effective approaches to software engineering. The bedrock that supports software engineering is a quality focus.

1.3软件工程

Figure 1.3 Software engineering layers

软件工程的基础是过程层。软件工程过程是将技术层粘合在一起的粘合剂,能够合理、及时地开发计算机软件。流程定义了为有效交付软件工程技术而必须建立的框架。软件过程构成了软件项目管理控制的基础,并建立了应用技术方法、生成工作产品(模型、文档、数据、报告、表格等)、建立里程碑、确保质量、并且变革得到妥善管理。

The foundation for software engineering is the process layer. The software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed.

软件工程方法提供了构建软件的技术指南。方法涵盖广泛的任务,包括沟通、需求分析、设计建模、程序构建、测试和支持。软件工程方法依赖于一组控制技术每个领域的基本原则,包括建模活动和其他描述性技术。

Software engineering methods provide the technical how-to’s for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques.

软件工程工具为过程和方法提供自动化或半自动化支持。当工具被集成,使得一种工具创建的信息可以被另一种工具使用时,就建立了一个支持软件开发的系统,称为计算机辅助软件工程。

Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

1.3 软件流程

1.3 The Software Process

流程是创建某些工作产品时执行的活动、操作和任务的集合一项活动致力于实现一个广泛的目标(例如,与利益相关者的沟通),并且无论应用领域、项目的规模、工作的复杂性或应用软件工程的严格程度如何,都可以应用该活动。一个动作(例如,架构设计)包含一组产生主要工作产品(例如,架构模型)的任务。任务侧重于一个小但定义明确的目标(例如,进行单元测试),该目标会产生切实的结果

A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied. An action (e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an architectural model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.

第10页在软件工程的背景下,过程并不是如何构建计算机软件的严格规定。相反,它是一种适应性强的方法,使工作人员(软件团队)能够挑选和选择适当的工作操作和任务集。我们的目的始终是及时、高质量地交付软件,以满足赞助者和使用者的需求。

Page 10In the context of software engineering, a process is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work (the software team) to pick and choose the appropriate set of work actions and tasks. The intent is always to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it.

1.3.1 流程框架

1.3.1 The Process Framework

过程框架通过识别适用于所有软件项目(无论其规模或复杂性)的少量框架活动,为完整的软件工程过程奠定了基础。此外,流程框架包含一组适用于整个软件流程的伞式活动。软件工程的通用过程框架包含五项活动:

A process framework establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process. A generic process framework for software engineering encompasses five activities:

沟通。在开始任何技术工作之前,与客户(和其他利益相关者)的沟通和协作至关重要。8目的是了解利益相关者的项目目标并收集有助于定义软件特性和功能的需求。

Communication. Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stakeholders).8 The intent is to understand stakeholders’ objectives for the project and to gather requirements that help define software features and functions.

规划。如果有地图,任何复杂的旅程都可以简化。软件项目是一个复杂的旅程,规划活动创建一个“地图”,帮助指导团队完成旅程。该地图(称为软件项目计划)通过描述要执行的技术任务、可能的风险、需要的资源、要生产的工作产品和工作时间表来定义软件工程工作。

Planning. Any complicated journey can be simplified if a map exists. A software project is a complicated journey, and the planning activity creates a “map” that helps guide the team as it makes the journey. The map—called a software project plan—defines the software engineering work by describing the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.

造型。无论您是园林设计师、桥梁建造者、航空工程师、木匠还是建筑师,您每天都会与模型打交道。您创建事物的“草图”,以便了解整体情况——它的架构是什么样子、各组成部分如何组合在一起,以及许多其他特征。如果需要,您可以将草图细化为越来越详细,以便更好地理解问题以及如何解决它。软件工程师通过创建模型来完成同样的事情,以更好地理解软件需求和实现这些需求的设计。

Modeling. Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an architect, you work with models every day. You create a “sketch” of the thing so that you’ll understand the big picture—what it will look like architecturally, how the constituent parts fit together, and many other characteristics. If required, you refine the sketch into greater and greater detail in an effort to better understand the problem and how you’re going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements.

建造。你设计的东西必须被建造。此活动结合了代码生成(手动或自动)和发现代码中的错误所需的测试。

Construction. What you design must be built. This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.

第11页部署。软件(作为完整的实体或部分完成的增量)交付给客户,客户评估交付的产品并根据评估提供反馈。

Page 11Deployment. The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.

这五个通用框架活动可以在开发小型、简单的程序时使用;创建网络应用程序;以及大型、复杂的基于计算机的系统的工程。在每种情况下,软件过程的细节将有很大不同,但框架活动保持不变。

These five generic framework activities can be used during the development of small, simple programs; the creation of Web applications; and for the engineering of large, complex computer-based systems. The details of the software process will be quite different in each case, but the framework activities remain the same.

对于许多软件项目,框架活动随着项目的进展而迭代应用。也就是说,沟通、规划、建模、构建和部署是通过多次项目迭代而重复应用的。每次迭代都会产生一个软件增量,为利益相关者提供整体软件特性和功能的子集。随着每一个增量的产生,软件变得越来越完整。

For many software projects, framework activities are applied iteratively as a project progresses. That is, communication, planning, modeling, construction, and deployment are applied repeatedly through a number of project iterations. Each iteration produces a software increment that provides stakeholders with a subset of overall software features and functionality. As each increment is produced, the software becomes more and more complete.

1.3.2 伞式活动

1.3.2 Umbrella Activities

软件工程过程框架活动由许多伞式活动补充。一般来说,伞式活动应用于整个软件项目,帮助软件团队管理和控制进度、质量、变更和风险。典型的保护伞活动包括:

Software engineering process framework activities are complemented by a number of umbrella activities. In general, umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include:

软件项目跟踪和控制。允许软件团队根据项目计划评估进度,并采取任何必要的措施来维持进度。

Software project tracking and control. Allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule.

风险管理。评估可能影响项目结果或产品质量的风险。

Risk management. Assesses risks that may affect the outcome of the project or the quality of the product.

软件质量保证。定义并开展确保软件质量所需的活动。

Software quality assurance. Defines and conducts the activities required to ensure software quality.

技术审查。评估软件工程工作产品,努力在错误传播到下一个活动之前发现并消除错误。

Technical reviews. Assess software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity.

测量。定义并收集流程、项目和产品衡量标准,帮助团队交付满足利益相关者需求的软件;可以与所有其他框架和伞式活动结合使用。

Measurement. Defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities.

软件配置管理。管理整个软件流程中变更的影响。

Software configuration management. Manages the effects of change throughout the software process.

可重用性管理。定义工作产品重用(包括软件组件)的标准并建立实现可重用组件的机制。

Reusability management. Defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components.

工作产品准备和生产。包含创建工作产品(例如模型、文档、日志、表单和列表)所需的活动。

Work product preparation and production. Encompasses the activities required to create work products such as models, documents, logs, forms, and lists.

本书后面将详细讨论每项伞式活动。

Each of these umbrella activities is discussed in detail later in this book.

1.3.3 工艺适应

1.3.3 Process Adaptation

在本节前面,我们注意到软件工程过程并不是软件团队必须教条地遵循的严格规定。相反,它应该是敏捷的和适应性强的(针对问题、项目、团队和组织文化)。因此,一个项目采用的流程可能与另一项目采用的流程显着不同。其中差异包括:第12页

Previously in this section, we noted that the software engineering process is not a rigid prescription that must be followed dogmatically by a software team. Rather, it should be agile and adaptable (to the problem, to the project, to the team, and to the organizational culture). Therefore, a process adopted for one project might be significantly different than a process adopted for another project. Among the differences are:Page 12

  • 活动、行动和任务的总体流程以及它们之间的相互依赖性

  • Overall flow of activities, actions, and tasks and the interdependencies among them

  • 每个框架活动中定义操作和任务的程度

  • Degree to which actions and tasks are defined within each framework activity

  • 工作产品被识别和需要的程度

  • Degree to which work products are identified and required

  • 质量保证活动的实施方式

  • Manner in which quality assurance activities are applied

  • 项目跟踪和控制活动的应用方式

  • Manner in which project tracking and control activities are applied

  • 描述过程的总体详细程度和严谨程度

  • Overall degree of detail and rigor with which the process is described

  • 客户和其他利益相关者参与项目的程度

  • Degree to which the customer and other stakeholders are involved with the project

  • 给予软件团队的自主权

  • Level of autonomy given to the software team

  • 团队组织和角色的规定程度

  • Degree to which team organization and roles are prescribed

在本书的第一部分中,我们相当详细地研究了软件过程。

In Part One of this book, we examine software process in considerable detail.

1.4 软件工程实践

1.4 Software Engineering Practice

1.3 节中,我们介绍了一个通用软件过程模型,该模型由一组建立软件工程实践框架的活动组成。通用框架活动(通信、规划、建模、构建部署)和伞式活动为软件工程工作建立了框架架构。但是软件工程的实践如何适应呢?在接下来的部分中,您将对适用于框架活动的通用概念和原则有基本的了解。9

In Section 1.3, we introduced a generic software process model composed of a set of activities that establish a framework for software engineering practice. Generic framework activities—communication, planning, modeling, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work. But how does the practice of software engineering fit in? In the sections that follow, you’ll gain a basic understanding of the generic concepts and principles that apply to framework activities.9

1.4.1 实践的本质

1.4.1 The Essence of Practice

在现代计算机出现之前写的经典著作《How to Solve It》中,George Polya [Pol45] 概述了问题解决的本质,进而概述了软件工程实践的本质:

In the classic book How to Solve It, written before modern computers existed, George Polya [Pol45] outlined the essence of problem solving, and consequently, the essence of software engineering practice:

  1. 了解问题(沟通和分析)。

  2. Understand the problem (communication and analysis).

  3. 规划解决方案(建模和软件设计)。

  4. Plan a solution (modeling and software design).

  5. 执行计划(代码生成)。

  6. Carry out the plan (code generation).

  7. 检查结果的准确性(测试和质量保证)。

  8. Examine the result for accuracy (testing and quality assurance).

在软件工程的背景下,这些常识性步骤引出了一系列基本问题[改编自 Pol45]:

In the context of software engineering, these commonsense steps lead to a series of essential questions [adapted from Pol45]:

了解问题。有时很难承认,但当我们遇到问题时,我们大多数人都会感到傲慢。我们听了几秒钟,然后想,哦,是的,我明白了,让我们继续解决这个问题吧。不幸的是,理解并不总是那么容易。值得花一点时间回答一些简单的问题:第13页

Understand the Problem. It’s sometimes difficult to admit, but most of us suffer from hubris when we’re presented with a problem. We listen for a few seconds and then think, Oh yeah, I understand, let’s get on with solving this thing. Unfortunately, understanding isn’t always that easy. It’s worth spending a little time answering a few simple questions:Page 13

  • 问题的解决与谁有利害关系?也就是说,利益相关者是谁?

  • Who has a stake in the solution to the problem? That is, who are the stakeholders?

  • 有哪些未知数?正确解决问题需要哪些数据、功能和特征?

  • What are the unknowns? What data, functions, and features are required to properly solve the problem?

  • 问题可以划分吗?是否可以表示更容易理解的较小问题?

  • Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?

  • 问题可以用图形表示吗?可以创建分析模型吗?

  • Can the problem be represented graphically? Can an analysis model be created?

规划解决方案。现在您了解了问题(或者您认为是这样),并且迫不及待地开始编码。在开始之前,先放慢速度并做一些设计:

Plan the Solution. Now you understand the problem (or so you think), and you can’t wait to begin coding. Before you do, slow down just a bit and do a little design:

  • 您以前见过类似的问题吗?潜在解决方案中是否存在可识别的模式?是否有现有软件可以实现所需的数据、功能和特性?

  • Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required?

  • 有类似的问题解决了吗?如果是这样,解决方案的元素可以重复使用吗?

  • Has a similar problem been solved? If so, are elements of the solution reusable?

  • 子问题可以定义吗?如果是这样,子问题的解决方案是否显而易见?

  • Can subproblems be defined? If so, are solutions readily apparent for the subproblems?

  • 您能否以能够有效实施的方式提出解决方案?可以创建设计模型吗?

  • Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?

执行计划。您创建的设计可作为您想要构建的系统的路线图。可能会有意想不到的弯路,也可能边走边发现更好的路线,但“计划”会让你继续前行而不会迷路。

Carry Out the Plan. The design you’ve created serves as a road map for the system you want to build. There may be unexpected detours, and it’s possible that you’ll discover an even better route as you go, but the “plan” will allow you to proceed without getting lost.

  • 解决方案是否符合计划?源代码是否可以追溯到设计模型?

  • Does the solution conform to the plan? Is source code traceable to the design model?

  • 解决方案的每个组成部分是否都被证明是正确的?设计和代码是否经过审查,或者更好的是,正确性证明是否已应用于算法?

  • Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to the algorithm?

检查结果。您不能确定您的解决方案是否完美,但您可以确定您已经设计了足够数量的测试来发现尽可能多的错误。

Examine the Result. You can’t be sure that your solution is perfect, but you can be sure that you’ve designed a sufficient number of tests to uncover as many errors as possible.

  • 是否可以测试解决方案的每个组成部分?是否实施了合理的测试策略?

  • Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?

  • 该解决方案产生的结果是否符合所需的数据、功能和特性?该软件是否已根据所有利益相关者的要求进行了验证?

  • Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?

这种方法大部分都是常识,这一点您应该不会感到惊讶。事实上,可以合理地说,软件工程的常识性方法永远不会让您误入歧途。

It shouldn’t surprise you that much of this approach is common sense. In fact, it’s reasonable to state that a commonsense approach to software engineering will never lead you astray.

第14页

Page 14

1.4.2 一般原则

1.4.2 General Principles

字典将“原则一词定义为“思想体系中所需的重要基本法则或假设”。在本书中,我们将讨论许多不同抽象级别的原则。一些关注软件工程作为一个整体,另一些关注特定的通用框架活动(例如,通信),还有一些关注软件工程操作(例如,架构设计)或技术任务(例如,创建使用场景)。无论其关注程度如何,原则都可以帮助您建立扎实的软件工程实践的思维模式。因此它们很重要。

The dictionary defines the word principle as “an important underlying law or assumption required in a system of thought.” Throughout this book we’ll discuss principles at many different levels of abstraction. Some focus on software engineering as a whole, others consider a specific generic framework activity (e.g., communication), and still others focus on software engineering actions (e.g., architectural design) or technical tasks (e.g., creating a usage scenario). Regardless of their level of focus, principles help you establish a mind-set for solid software engineering practice. They are important for that reason.

David Hooker [Hoo96] 提出了七个原则,重点关注整个软件工程实践。它们转载于以下段落:10

David Hooker [Hoo96] has proposed seven principles that focus on software engineering practice as a whole. They are reproduced in the following paragraphs:10

第一条原则: 一切存在的原因

The First Principle: The Reason It All Exists

软件系统存在的原因只有一个:为用户提供价值。所有决定都应考虑到这一点。在指定系统要求之前,在注意某个系统功能之前,在确定硬件平台或开发流程之前,先问自己一些问题,例如:“这是否为系统增加了真正的价值?” 如果答案是否定的,请不要这样做。所有其他原则都支持这一原则。

A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: “Does this add real value to the system?” If the answer is no, don’t do it. All other principles support this one.

第二条原则: KISS(保持简单,愚蠢!)

The Second Principle: KISS (Keep It Simple, Stupid!)

在任何设计工作中都需要考虑许多因素。所有的设计都应该尽可能简单,但又不能简单。这有助于拥有更容易理解和维护的系统。这并不是说应该以简单的名义放弃功能。事实上,越优雅的设计通常越简单。简单并不意味着“快速而肮脏”。通常需要进行大量思考并进行多次迭代才能简化设计。回报是软件更易于维护且不易出错。

There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily maintained system. This is not to say that features should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the simpler ones. Simple does not mean “quick and dirty.” It often takes a lot of thought and work over multiple iterations to simplify the design. The payoff is software that is more maintainable and less error-prone.

第三条原则: 保持愿景

The Third Principle: Maintain the Vision

清晰的愿景对于软件项目的成功至关重要。如果没有概念完整性,系统就有可能成为由不兼容的设计拼凑而成,并由错误类型的螺丝固定在一起。。。损害软件系统的架构愿景会削弱甚至最终破坏设计良好的系统。拥有一位能够保持愿景并强制执行合规性的授权架构师有助于确保软件项目非常成功。

A clear vision is essential to the success of a software project. Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws . . . Compromising the architectural vision of a software system weakens and will eventually break even the well-designed systems. Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project.

第四条原则: 你生产什么,别人就会消费什么

The Fourth Principle: What You Produce, Others Will Consume

始终指定、设计、记录和实施,知道其他人必须理解您在做什么。任何软件开发产品的受众都可能很大。着眼于用户进行指定。设计时,牢记实施者。为那些必须维护和扩展系统的人编写代码。有人可能必须调试您编写的代码,这使他们成为您代码的用户。让他们的工作变得更轻松可以增加系统的价值。

Always specify, design, document, and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern for those that must maintain and extend the system. Someone may have to debug the code you write, and that makes them a user of your code. Making their job easier adds value to the system.

第15页

Page 15

第五条原则: 对未来持开放态度

The Fifth Principle: Be Open to the Future

在当今的计算环境中,规格会随时发生变化,硬件平台在几个月后就会过时,软件生命周期通常以月而不是几年来衡量。然而,真正的“工业强度”软件系统必须持续更长时间。为此,系统必须做好适应这些和其他变化的准备。成功做到这一点的系统从一开始就是这样设计的。永远不要让自己陷入困境。始终询问“如果”,并通过创建解决一般问题(而不仅仅是特定问题)的系统来为所有可能的答案做好准备。11

In today’s computing environments, where specifications change on a moment’s notice and hardware platforms are obsolete just a few months old, software lifetimes are typically measured in months instead of years. However, true “industrial-strength” software systems must endure far longer. To do this, systems must be ready to adapt to these and other changes. Systems that do this successfully have been designed this way from the start. Never design yourself into a corner. Always ask “what if,” and prepare for all possible answers by creating systems that solve the general problem, not just the specific one.11

第六条原则: 提前计划重用

The Sixth Principle: Plan Ahead for Reuse

重复使用可以节省时间和精力。12实现高水平的重用可以说是开发软件系统中最难实现的目标。代码和设计的重用已被认为是使用面向对象技术的主要好处。然而,这项投资的回报并不是自动的。提前规划重用可以降低成本并增加可重用组件及其所包含的系统的价值

Reuse saves time and effort.12 Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system. The reuse of code and designs has been proclaimed as a major benefit of using object-oriented technologies. However, the return on this investment is not automatic. Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.

第七条原则: 思考!

The Seventh Principle: Think!

最后一条原则可能是最容易被忽视的。在行动之前进行清晰、完整的思考几乎总是会产生更好的结果。当你思考某件事时,你更有可能做对。您还可以获得有关如何再次正确行事的知识。如果你确实思考过某件事但仍然做错了,那么它就会成为一次宝贵的经历。思考的一个副作用是学会识别你不知道的东西,此时你可以研究答案。当清晰的思想进入系统时,价值就会显现出来。应用前六个原则需要深入思考,而潜在的回报是巨大的。

This last principle is probably the most overlooked. Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right. You also gain knowledge about how to do it right again. If you do think about something and still do it wrong, it becomes a valuable experience. A side effect of thinking is learning to recognize when you don’t know something, at which point you can research the answer. When clear thought has gone into a system, value comes out. Applying the first six principles requires intense thought, for which the potential rewards are enormous.

如果每个软件工程师和每个软件团队都简单地遵循胡克的七个原则,那么我们在构建复杂的基于计算机的系统时遇到的许多困难都将被消除。

If every software engineer and every software team simply followed Hooker’s seven principles, many of the difficulties we experience in building complex computer-based systems would be eliminated.

1.5 一切是如何开始的

1.5 How It All Starts

每个软件项目都是由某些业务需求促成的——需要纠正现有应用程序中的缺陷;需要使“遗留系统”适应不断变化的业务环境;需要扩展现有应用程序的功能和特性;或需要创建新产品、服务或系统。

Every software project is precipitated by some business need—the need to correct a defect in an existing application; the need to adapt a “legacy system” to a changing business environment; the need to extend the functions and features of an existing application; or the need to create a new product, service, or system.

第16页在软件项目开始时,业务需求通常作为简单对话的一部分非正式地表达。侧边栏中呈现的对话是典型的。

Page 16At the beginning of a software project, the business need is often expressed informally as part of a simple conversation. The conversation presented in the sidebar is typical.

除了顺便提及之外,谈话中几乎没有提及软件。然而,软件将决定SafeHome产品线的成败。只有SafeHome软件成功,工程工作才会成功。只有当产品中嵌入的软件正确满足客户(尚未明确)的需求时,市场才会接受该产品。我们将在接下来的许多章节中跟踪SafeHome软件工程的进展。

With the exception of a passing reference, software was hardly mentioned as part of the conversation. And yet, software will make or break the SafeHome product line. The engineering effort will succeed only if SafeHome software succeeds. The market will accept the product only if the software embedded within it properly meets the customer’s (as yet unstated) needs. We’ll follow the progression of SafeHome software engineering in many of the chapters that follow.

第17页

Page 17

1.6 总结

1.6 Summary

软件是基于计算机的系统和产品发展的关键要素,也是世界舞台上最重要的技术之一。在过去的 60 年里,软件已经从专门的问题解决和信息分析工具发展成为一个独立的行业。然而,我们仍然难以在预算范围内按时开发高质量的软件。

Software is the key element in the evolution of computer-based systems and products and one of the most important technologies on the world stage. Over the past 60 years, software has evolved from a specialized problem-solving and information analysis tool to an industry in itself. Yet we still have trouble developing high-quality software on time and within budget.

软件(程序、数据和描述性信息)涉及广泛的技术和应用领域。遗留软件继续给那些必须维护它的人带来特殊的挑战。

Software—programs, data, and descriptive information—addresses a wide array of technology and application areas. Legacy software continues to present special challenges to those who must maintain it.

软件工程包含能够及时、高质量地构建复杂的基于计算机的系统的过程、方法和工具。软件过程包含五个框架活动——沟通、规划、建模、构建和部署——适用于所有软件项目。软件工程实践是遵循一组核心原则的解决问题的活动。随着您对软件工程的了解越来越多,您将开始理解为什么在开始任何软件项目时应考虑这些原则。

Software engineering encompasses process, methods, and tools that enable complex computer-based systems to be built in a timely manner with quality. The software process incorporates five framework activities—communication, planning, modeling, construction, and deployment—that are applicable to all software projects. Software engineering practice is a problem-solving activity that follows a set of core principles. As you learn more about software engineering, you’ll begin to understand why these principles should be considered when beginning any software project.

问题与思考点

Problems and Points to Ponder

1.1. 提供至少五个额外示例,说明意外后果法则如何适用于计算机软件。

1.1. Provide at least five additional examples of how the law of unintended consequences applies to computer software.

1.2. 提供一些例子(正面和负面)来表明软件对我们社会的影响。

1.2. Provide a number of examples (both positive and negative) that indicate the impact of software on our society.

1.3. 针对第 1.1 节开头提出的五个问题制定您自己的答案。与你的同学讨论它们。

1.3. Develop your own answers to the five questions asked at the beginning of Section 1.1. Discuss them with your fellow students.

1.4. 许多现代应用程序经常发生变化——在将它们呈现给最终用户之前,然后在第一个版本投入使用之后。提出几种构建软件的方法,以阻止因变化而恶化。

1.4. Many modern applications change frequently—before they are presented to the end user and then after the first version has been put into use. Suggest a few ways to build software to stop deterioration due to change.

1.5. 考虑第 1.1.2 节中介绍的七个软件类别。您认为相同的软件工程方法可以应用于每种方法吗?解释你的答案。

1.5. Consider the seven software categories presented in Section 1.1.2. Do you think that the same approach to software engineering can be applied for each? Explain your answer.

1.6. 随着软件变得越来越普遍,公众面临的风险(由于错误的程序)变得越来越重要。设计一个世界末日但现实的场景,其中计算机程序的失败可能会造成巨大的经济或人类伤害。

1.6. As software becomes more pervasive, risks to the public (due to faulty programs) become an increasingly significant concern. Develop a doomsday but realistic scenario in which the failure of a computer program could do great harm, either economic or human.

1.7. 用你自己的话描述一个流程框架。当我们说框架活动适用于所有项目时,这是否意味着相同的工作任务适用于所有项目,无论其规模和复杂程度如何?解释。

1.7. Describe a process framework in your own words. When we say that framework activities are applicable to all projects, does this mean that the same work tasks are applied for all projects, regardless of size and complexity? Explain.

1.8. 伞形活动发生在整个软件过程中。您认为它们是均匀地应用于整个流程,还是集中在一项或多项框架活动中?

1.8. Umbrella activities occur throughout the software process. Do you think they are applied evenly across the process, or are some concentrated in one or more framework activities?

1在本书后面,我们将把这些人称为“利益相关者”。

1 We will call these people “stakeholders” later in this book.

2在一本关于软件业务的优秀论文集中,Tom DeMarco [DeM95] 提出了相反的观点。他表示:“我们不应该问为什么软件成本如此之高,而应该开始问‘我们做了什么才能使今天的软件成本如此之低?’” 这个问题的答案将帮助我们继续取得让软件行业脱颖而出的非凡成就。”

2 In an excellent book of essays on the software business, Tom DeMarco [DeM95] argues the counterpoint. He states: “Instead of asking why software costs so much, we need to begin asking ‘What have we done to make it possible for today’s software to cost so little?’ The answer to that question will help us continue the extraordinary level of achievement that has always distinguished the software industry.”

3事实上,从开发开始的那一刻起,早在第一个版本交付之前,各种不同的利益相关者可能会要求进行更改。

3 In fact, from the moment that development begins and long before the first version is delivered, changes may be requested by a variety of different stakeholders.

4如果输入、处理和输出的顺序和时间是可预测的,则软件是确定的。如果无法提前预测输入、处理和输出的顺序和时间,则软件是不确定的。

4 Software is determinate if the order and timing of inputs, processing, and outputs is predictable. Software is indeterminate if the order and timing of inputs, processing, and outputs cannot be predicted in advance.

5启发法是一种解决问题的方法,它采用实用方法或“经验法则”,不能保证完美,但足以完成手头的任务。

5 The use of heuristics is an approach to problem solving that employs a practical method or “rule of thumb” not guaranteed to be perfect, but sufficient for the task at hand.

6在这种情况下,质量是根据现代软件工程思维来判断的——这是一个有点不公平的标准,因为一些现代软件工程概念和原则在开发遗留软件时可能还没有得到很好的理解。

6 In this case, quality is judged based on modern software engineering thinking—a somewhat unfair criterion since some modern software engineering concepts and principles may not have been well understood at the time that the legacy software was developed.

7本书第三部分讨论了质量管理和相关方法。

7 Quality management and related approaches are discussed throughout Part Three of this book.

8利益相关者是指与项目成功结果有利害关系的任何人——业务经理、最终用户、软件工程师、支持人员等。罗布·汤姆塞特 (Rob Thomsett) 开玩笑说:“利益相关者是指持有大量股份的人。。。。如果你不照顾利益相关者,你就会知道股份最终会流向何处。”

8 A stakeholder is anyone who has a stake in the successful outcome of the project—business managers, end users, software engineers, support people, and so forth. Rob Thomsett jokes that, “a stakeholder is a person holding a large and sharp stake. . . . If you don’t look after your stakeholders, you know where the stake will end up.”

9当我们在本书后面讨论具体的软件工程方法和总体活动时,您应该重新访问本章中的相关章节。

9 You should revisit relevant sections within this chapter as we discuss specific software engineering methods and umbrella activities later in this book.

10经作者许可转载[Hoo96]。Hooker 在 http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment 中定义了这些原则的模式。

10 Reproduced with permission of the author [Hoo96]. Hooker defines patterns for these principles at http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment.

11如果采取极端的话,这个建议可能会很危险。针对“一般问题”进行设计有时需要在性能上做出妥协,并且可能会使特定的解决方案效率低下。

11 This advice can be dangerous if it is taken to extremes. Designing for the “general problem” sometimes requires performance compromises and can make specific solutions inefficient.

12虽然对于那些在未来项目中重用软件的人来说确实如此,但对于那些必须设计和构建可重用组件的人来说,重用的成本可能会很高。研究表明,设计和构建可重用组件的成本比构建目标软件高出 25% 到 200%。在某些情况下,成本差异是不合理的。

12 Although this is true for those who reuse the software on future projects, reuse can be expensive for those who must design and build reusable components. Studies indicate that designing and building reusable components can cost between 25 to 200 percent more than building targeted software. In some cases, the cost differential cannot be justified.

13 本书将使用SafeHome来说明项目团队在构建软件产品时的内部运作。公司、项目、人都是虚构的,但情况和问题却是真实的。

13 SafeHome will be used throughout this book to illustrate the inner workings of project teams as they build a software product. The company, the project, and the people are purely fictitious, but the situations and problems are real.

第19页

Page 19

部分 软件流程

PART One The Software Process

在软件工程:从业者方法的这一部分中,您将了解为软件工程实践提供框架的过程。这些问题将在以下章节中讨论:

In this part of Software Engineering: A Practitioner’s Approach, you’ll learn about the process that provides a framework for software engineering practice. These questions are addressed in the chapters that follow:

  • 什么是软件流程?

  • What is a software process?

  • 每个软件流程中存在哪些通用框架活动?

  • What are the generic framework activities that are present in every software process?

  • 如何对流程进行建模?什么是流程模式?

  • How are processes modeled, and what are process patterns?

  • 规范性流程模型有哪些?它们的优点和缺点是什么?

  • What are the prescriptive process models, and what are their strengths and weaknesses?

  • 为什么敏捷性是现代软件工程工作的口号?

  • Why is agility a watchword in modern software engineering work?

  • 什么是敏捷软件开发,它与更传统的流程​​模型有何不同?

  • What is agile software development, and how does it differ from more traditional process models?

一旦回答了这些问题,您就可以更好地理解软件工程实践的应用背景。

Once these questions are answered, you’ll be better prepared to understand the context in which software engineering practice is applied.

第20页

Page 20

章节

chapter

2过程模型

2 Process Models

构建计算机软件是一个迭代的社会学习过程,其结果被 Baetjer [Bae98] 称为“软件资本”,是在该过程进行时收集、提炼和​​组织的知识的体现。

Building computer software is an iterative social learning process, and the outcome, something that Baetjer [Bae98] would call “software capital,” is an embodiment of knowledge collected, distilled, and organized as the process is conducted.

但从技术角度来看,软件流程到底是什么?在本书中,我们将软件过程定义为构建高质量软件所需的活动、操作和任务的框架。“过程”与“软件工程”同义吗?答案是肯定和否定。软件过程定义了软件设计时所采用的方法。但软件工程还包含填充流程的技术——技术方法和自动化工具。

But what exactly is a software process from a technical point of view? Within the context of this book, we define a software process as a framework for the activities, actions, and tasks required to build high-quality software. Is “process” synonymous with “software engineering”? The answer is yes and no. A software process defines the approach that is taken as software is engineered. But software engineering also encompasses technologies that populate the process—technical methods and automated tools.

更重要的是,软件工程是由富有创造力、知识渊博的人员执行的,他们应该调整成熟的软件流程,使其适合他们构建的产品和市场的需求。

More important, software engineering is performed by creative, knowledgeable people who should adapt a mature software process so that it is appropriate for the products that they build and the demands of their marketplace.

第21页

Page 21

2.1 通用过程模型

2.1 A Generic Process Model

第一章中,流程被定义为创建某些工作产品时执行的活动、操作和任务的集合。这些活动、操作和任务中的每一项都驻留在一个框架或模型中,该框架或模型定义了它们与流程以及彼此之间的关系。

In Chapter 1, a process was defined as a collection of activities, actions, and tasks that are performed when some work product is to be created. Each of these activities, actions, and tasks resides within a framework or model that defines their relationship with the process and with one another.

软件流程如图 2.1所示。参考该图,每个框架活动都由一组软件工程操作填充。每个软件工程操作都由任务集定义,该任务集标识要完成的工作任务、将生成的工作产品、所需的质量保证点以及将用于指示进度的里程碑。

The software process is represented schematically in Figure 2.1. Referring to the figure, each framework activity is populated by a set of software engineering actions. Each software engineering action is defined by a task set that identifies the work tasks that are to be completed, the work products that will be produced, the quality assurance points that will be required, and the milestones that will be used to indicate progress.

图2.1软件流程 框架

Figure 2.1 A software process framework

正如我们在第 1 章中讨论的,软件工程的通用过程框架定义了五个框架活动——通信、规划、建模、构建部署。此外,在整个过程中还应用了一系列伞式活动——项目跟踪和控制、风险管理、质量保证、配置管理、技术审查等。第22页

As we discussed in Chapter 1, a generic process framework for software engineering defines five framework activities—communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities—project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others—are applied throughout the process.Page 22

您应该注意到,软件过程的一个重要方面尚未讨论。这个方面(称为流程)描述了框架活动以及每个框架活动中发生的操作和任务如何按照顺序和时间进行组织。如图 2.2所示。

You should note that one important aspect of the software process has not been discussed yet. This aspect—called process flow—describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time. It is illustrated in Figure 2.2.

图2.2 工艺流程_

Figure 2.2 Process flow

线性流程按顺序执行五个框架活动中的每一个,从通信开始,到部署结束(图 2.2a)。迭代流程会重复一个或多个活动,然后再进行下一个活动(图 2.2b)。演化过程流以“循环”方式执行活动。通过五个活动的每个电路都会产生一个更完整的软件版本(图 2.2c)。并行流程(图2.2d)与其他活动并行执行一个或多个活动(例如,软件一方面的建模可能与软件另一方面的构建并行执行)。

A linear process flow executes each of the five framework activities in sequence, beginning with communication and culminating with deployment (Figure 2.2a). An iterative process flow repeats one or more of the activities before proceeding to the next (Figure 2.2b). An evolutionary process flow executes the activities in a “circular” manner. Each circuit through the five activities leads to a more complete version of the software (Figure 2.2c). A parallel process flow (Figure 2.2d) executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect of the software).

第23页

Page 23

2.2 定义框架活动

2.2 Defining a Framework Activity

尽管我们在第 1 章中描述了五个框架活动并提供了每个活动的基本定义,但软件团队在能够作为软件流程的一部分正确执行这些活动中的任何一个之前,将需要更多的信息。因此,您面临一个关键问题:考虑到要解决的问题的性质、工作人员的特征以及赞助该项目的利益相关者,哪些行动适合框架活动?

Although we have described five framework activities and provided a basic definition of each in Chapter 1, a software team would need significantly more information before it could properly execute any one of these activities as part of the software process. Therefore, you are faced with a key question: What actions are appropriate for a framework activity, given the nature of the problem to be solved, the characteristics of the people doing the work, and the stakeholders who are sponsoring the project?

对于由一个人(在远程位置)请求且要求简单、直接的小型软件项目,通信活动可能只不过是与适当的利益相关者进行电话或电子邮件。因此,唯一必要的操作是电话交谈,并且该操作包含的工作任务(任务集)是:

For a small software project requested by one person (at a remote location) with simple, straightforward requirements, the communication activity might encompass little more than a phone call or e-mail with the appropriate stakeholder. Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that this action encompasses are:

  1. 通过电话与利益相关者取得联系。

  2. Make contact with stakeholder via telephone.

  3. 讨论需求并制定注释。

  4. Discuss requirements and develop notes.

  5. 将笔记整理成简短的书面要求说明。

  6. Organize notes into a brief written statement of requirements.

  7. 通过电子邮件发送给利益相关者以供审核和批准。

  8. E-mail to stakeholder for review and approval.

如果项目相当复杂,有很多利益相关者,每个利益相关者都有一组不同的(有时是相互冲突的)需求,那么沟通活动可能有六种不同的操作:启动、启发、阐述、谈判、规范验证这些软件工程操作中的每一个都可能有许多工作任务,并且在某些情况下有许多不同的工作产品。

If the project was considerably more complex with lots of stakeholders, each with a different set of (sometimes conflicting) requirements, the communication activity might have six distinct actions: inception, elicitation, elaboration, negotiation, specification, and validation. Each of these software engineering actions might have many work tasks and in some cases a number of distinct work products.

2.3 识别任务集

2.3 Identifying a Task Set

再次参考图 2.1,每个软件工程操作(例如,启发、与通信活动相关的操作)可以由许多不同的任务集来表示- 每个任务集都是软件工程工作任务、相关工作产品、质量保证点的集合和项目里程碑。不同的项目需要不同的任务集。您应该选择最适合项目需求和团队特点的任务集。这意味着软件工程行动应该适应软件项目的特定需求和项目团队的特征。第24页

Referring again to Figure 2.1, each software engineering action (e.g., elicitation, an action associated with the communication activity) can be represented by a number of different task sets—each a collection of software engineering work tasks, related work products, quality assurance points, and project milestones. Different projects demand different task sets. You should choose a task set that best accommodates the needs of the project and the characteristics of your team. This implies that a software engineering action should be adapted to the specific needs of the software project and the characteristics of the project team.Page 24

2.4 过程评估和改进

2.4 Process Assessment and Improvement

软件过程的存在并不能保证软件能够按时交付、能够满足客户的需求或者能够展现出导致长期质量特征的技术特征(第15章。过程模式必须与可靠的软件工程实践相结合(本书的第二部分)。此外,还可以评估流程本身,以确保其满足一组基本流程标准,这些标准已被证明对于成功的软件工程至关重要。1

The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term quality characteristics (Chapter 15). Process patterns must be coupled with solid software engineering practice (Part Two of this book). In addition, the process itself can be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for successful software engineering.1

大多数工程师当前的想法是,应使用数字测量或软件分析(指标)来评估软件流程和活动。这第25页您在实现有效软件流程的过程中所取得的进展将定义您可以以有意义的方式衡量改进的程度。第 17 章介绍了使用软件过程度量来评估过程质量。第 28 章对过程评估和改进方法进行了更详细的讨论。

The current thinking among most engineers is that software processes and activities should be assessed using numeric measures or software analytics (metrics). The Page 25progress you have made in a journey toward an effective software process will define the degree to which you can measure improvement in a meaningful way. The use of software process metrics to assess process quality is introduced in Chapter 17. A more detailed discussion of process assessment and improvement methods is presented in Chapter 28.

2.5 规定的过程模型

2.5 Prescriptive Process Models

规范性流程模型定义了一组预定义的流程元素和可预测的流程工作流程。规范性过程模型2力求软件开发的结构和顺序。活动和任务按照既定的进度指南顺序进行。但是规范性模型是否适合在变化中蓬勃发展的软件世界?如果我们拒绝传统的流程​​模型(以及它们所暗示的顺序)并用结构化程度较低的模型替代它们,那么我们是否就无法在软件工作中实现协调性和连贯性?

Prescriptive process models define a predefined set of process elements and a predictable process work flow. Prescriptive process models2 strive for structure and order in software development. Activities and tasks occur sequentially with defined guidelines for progress. But are prescriptive models appropriate for a software world that thrives on change? If we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

这些问题没有简单的答案,但软件工程师有其他选择。在接下来的部分中,我们概述了规范性流程方法,其中顺序和项目一致性是主要问题。我们称它们为“规定性”,因为它们规定了一组流程元素——框架活动、软件工程操作、任务、工作产品、质量保证和每个项目的变更控制机制。每个过程模型还规定了一个过程流(也称为工作流),即过程元素相互关联的方式。

There are no easy answers to these questions, but there are alternatives available to software engineers. In the sections that follow, we provide an overview of the prescriptive process approach in which order and project consistency are dominant issues. We call them “prescriptive” because they prescribe a set of process elements—framework activities, software engineering actions, tasks, work products, quality assurance, and change control mechanisms for each project. Each process model also prescribes a process flow (also called a work flow)—that is, the manner in which the process elements are interrelated to one another.

所有软件过程模型都可以容纳第 1 章中描述的通用框架活动,但每个模型对这些活动应用不同的重点,并定义以不同方式调用每个框架活动(以及软件工程操作和任务)的过程流。在第 3 章和第 4章中,我们将讨论软件工程实践,这些实践努力适应许多软件项目开发过程中不可避免的变化。

All software process models can accommodate the generic framework activities described in Chapter 1, but each applies a different emphasis to these activities and defines a process flow that invokes each framework activity (as well as software engineering actions and tasks) in a different manner. In Chapters 3 and 4 we will discuss software engineering practices that strive to accommodate the changes that are inevitable during the development of many software projects.

2.5.1 瀑布模型

2.5.1 The Waterfall Model

有时,问题的需求可以很好地理解——工作以相当线性的方式从通信流向部署。当必须对现有系统进行明确的调整或增强时(例如,对会计软件进行调整,因为它需要适应强制性政府法规的变化),有时会遇到这种情况。它也可能发生在有限数量的新开发工作中,但前提是需求已明确定义且相当稳定。

There are times when the requirements for a problem are well understood—when work flows from communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well-defined adaptations or enhancements to an existing system must be made (e.g., an adaptation to accounting software because it needs to accommodate changes to mandated government regulations). It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable.

瀑布模型,有时称为线性顺序模型,提出了一种系统的、顺序的软件开发方法3,该方法从客户的需求规范开始,然后通过规划、建模、构建和部署进行,最终为已完成的软件提供持续支持(图2.3)。第26页

The waterfall model, sometimes called the linear sequential model, suggests a systematic, sequential approach3 to software development that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment, culminating in ongoing support of the completed software (Figure 2.3).Page 26

2.3 瀑布模型

Figure 2.3 The waterfall model

瀑布模型是软件工程最古老的范例。然而,在过去的五年里,对这一流程模型的批评甚至导致了热心支持者对其有效性的质疑。应用瀑布模型时有时会遇到的问题包括:

The waterfall model is the oldest paradigm for software engineering. However, over the past five decades, criticism of this process model has caused even ardent supporters to question its efficacy. Among the problems that are sometimes encountered when the waterfall model is applied are:

  1. 实际项目很少遵循模型提出的顺序工作流程。

  2. Real projects rarely follow the sequential work flow that the model proposes.

  3. 客户通常很难在大多数项目开始时明确说明所有要求。

  4. It is often difficult for the customer to state all requirements explicitly at the beginning of most projects.

  5. 客户必须有耐心,因为直到项目时间跨度后期才会提供程序的工作版本。

  6. The customer must have patience because a working version of the program(s) will not be available until late in the project time span.

  7. 在审查工作计划之前,可能无法发现重大错误。

  8. Major blunders may not be detected until the working program is reviewed.

如今,软件工作节奏很快,并且面临着永无休止的变化(特性、功能和信息内容)。瀑布模型通常不适合此类工作。

Today, software work is fast paced and subject to a never-ending stream of changes (to features, functions, and information content). The waterfall model is often inappropriate for such work.

2.5.2 原型流程模型

2.5.2 Prototyping Process Model

通常,客户定义了一组软件的总体目标,但没有确定功能和特性的详细要求。在其他情况下,开发人员可能不确定算法的效率、操作系统的适应性或人机交互应采取的形式。在这些以及许多其他情况下,原型设计范式可能提供最佳方法。

Often, a customer defines a set of general objectives for software but does not identify detailed requirements for functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human-machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach.

虽然原型设计可以用作独立的流程模型,但它更常用作一种可以在本章提到的任何一个流程模型的上下文中实现的技术。无论以何种方式应用,原型范式都可以帮助您和其他利益相关者更好地理解当需求模糊时要构建什么。第27页

Although prototyping can be used as a stand-alone process model, it is more commonly used as a technique that can be implemented within the context of any one of the process models noted in this chapter. Regardless of the manner in which it is applied, the prototyping paradigm assists you and other stakeholders to better understand what is to be built when requirements are fuzzy.Page 27

例如,使用增量原型开发的健身应用程序可能会提供将手机与健身设备同步并显示当前数据所需的基本用户界面屏幕;第二个原型可能包含设定目标和在云上存储健身设备数据的能力,根据客户的反馈创建和修改用户界面屏幕;第三个原型可能包括社交媒体集成,允许用户设定健身目标并与一群朋友分享目标进度。

For example, a fitness app developed using incremental prototypes might deliver the basic user interface screens needed to sync a mobile phone with the fitness device and display the current data; the ability to set goals and store the fitness device data on the cloud might be included in the second prototype, creating and modifying the user interface screens based on customers feedback; and a third prototype might include social media integration to allow users to set fitness goals and share progress toward them with a set of friends.

原型设计范式(图 2.4)从沟通开始。您与其他利益相关者会面,定义软件的总体目标,确定已知的需求,并概述必须进一步定义的领域。快速规划原型迭代,并进行建模(以“快速设计”的形式)。快速设计侧重于最终用户可见的软件方面的表示(例如,人机界面布局或输出显示格式)。快速设计导致了原型的构建。原型由利益相关者部署和评估,利益相关者提供用于进一步细化需求的反馈。当原型被调整以满足不同利益相关者的需求时,就会发生迭代,同时使您能够更好地理解需要做什么。

The prototyping paradigm (Figure 2.4) begins with communication. You meet with other stakeholders to define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A prototyping iteration is planned quickly, and modeling (in the form of a “quick design”) occurs. A quick design focuses on a representation of those aspects of the software that will be visible to end users (e.g., human interface layout or output display formats). The quick design leads to the construction of a prototype. The prototype is deployed and evaluated by stakeholders, who provide feedback that is used to further refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the same time enabling you to better understand what needs to be done.

图2.4原型 范例

Figure 2.4 The prototyping paradigm

理想情况下,原型可以作为识别软件需求的机制。如果要构建工作原型,您可以利用现有的程序片段或应用能够快速生成工作程序的工具。第28页

Ideally, the prototype serves as a mechanism for identifying software requirements. If a working prototype is to be built, you can make use of existing program fragments or apply tools that enable working programs to be generated quickly.Page 28

利益相关者和软件工程师都喜欢原型设计范例。用户可以感受到实际的系统,开发人员可以立即构建一些东西。然而,由于以下原因,原型设计可能会出现问题:

Both stakeholders and software engineers like the prototyping paradigm. Users get a feel for the actual system, and developers get to build something immediately. Yet, prototyping can be problematic for the following reasons:

  1. 利益相关者看到的是软件的工作版本。他们可能没有意识到原型架构(程序结构)也在不断发展。这意味着开发人员可能没有考虑软件的整体质量或长期可维护性。

  2. Stakeholders see what appears to be a working version of the software. They may be unaware that the prototype architecture (program structure) is also evolving. This means that the developers may not have considered the overall software quality or long-term maintainability.

  3. 作为一名软件工程师,您可能会试图在实现上做出妥协,以使原型快速运行。如果你不小心,这些不太理想的选择现在已经成为不断发展的系统的一个组成部分。

  4. As a software engineer, you may be tempted to make implementation compromises to get a prototype working quickly. If you are not careful, these less-than-ideal choices have now become an integral part of the evolving system.

第29页

Page 29

尽管可能会出现问题,但原型设计可以成为软件工程的有效范例。关键是一开始就定义好游戏规则;也就是说,所有利益相关者都应该同意原型的构建部分是为了充当定义需求的机制。通常需要设计一个原型,以便将其演变成最终产品。现实情况是,开发人员可能需要放弃(至少部分放弃)原型,以更好地满足客户不断变化的需求。

Although problems can occur, prototyping can be an effective paradigm for software engineering. The key is to define the rules of the game at the beginning; that is, all stakeholders should agree that the prototype is built in part to serve as a mechanism for defining requirements. It is often desirable to design a prototype so it can be evolved into the final product. The reality is developers may need to discard (at least in part) a prototype to better meet the customer’s evolving needs.

2.5.3 演化过程模型

2.5.3 Evolutionary Process Model

像所有复杂的系统一样,软件会随着时间的推移而发展。随着开发的进行,业务和产品需求经常发生变化,从而导致最终产品的直线路径不切实际。紧迫的市场期限可能导致无法完成全面的软件产品。可以创建产品的有限版本来满足竞争或业务压力,并在更好地理解所有系统功能后发布改进的版本。在这种情况下,您需要一个经过明确设计的流程模型,以适应不断增长和变化的产品。

Software, like all complex systems, evolves over time. Business and product requirements often change as development proceeds, making a straight-line path to an end product unrealistic. Tight market deadlines may make completion of a comprehensive software product impossible. It might be possible to create a limited version of a product to meet competitive or business pressure and release a refined version once all system features are better understood. In a situation like this you need a process model that has been explicitly designed to accommodate a product that grows and changes.

螺旋模型最初由 Barry Boehm [Boe88] 提出,是一种演化的软件过程模型,它将原型设计的迭代性质与瀑布模型的受控和系统方面结合起来。它提供了快速开发越来越完整的软件版本的潜力。

Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. It provides the potential for rapid development of increasingly more complete versions of the software.

使用螺旋模型,软件以一系列渐进的版本进行开发。在早期迭代期间,发布的版本可能是模型或原型。在以后的迭代中,会产生越来越完整的工程系统版本。

Using the spiral model, software is developed in a series of evolutionary releases. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.

螺旋模型分为一组由软件工程团队定义的框架活动。出于说明目的,我们使用前面讨论的通用框架活动。4每个框架活动代表图 2.5所示螺旋路径的一段。当这个进化过程开始时,软件团队执行从中心开始以顺时针方向围绕螺旋的一圈所暗示的活动。每次革命时都会考虑风险(第 26 章)。锚点里程碑——沿着螺旋路径达到的工作产品和条件的组合——在每次进化过程中都会被记录下来。

A spiral model is divided into a set of framework activities defined by the software engineering team. For illustrative purposes, we use the generic framework activities discussed earlier.4 Each of the framework activities represent one segment of the spiral path illustrated in Figure 2.5. As this evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk (Chapter 26) is considered as each revolution is made. Anchor point milestones—a combination of work products and conditions that are attained along the path of the spiral—are noted for each evolutionary pass.

图2.5典型 螺旋模型

Figure 2.5 A typical spiral model

围绕螺旋的第一个回路(从最靠近中心的内部流线开始,如图2.5所示)可能会导致产品规格的开发;随后的螺旋循环可用于开发原型,然后逐步开发更复杂的软件版本。每次经过规划区域都会导致项目计划的调整。成本和进度根据交付后客户的反馈进行调整。此外,项目经理还调整完成软件所需的计划迭代次数。

The first circuit around the spiral (beginning at the inside streamline nearest the center, as shown in Figure 2.5) might result in the development of a product specification; subsequent passes around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted based on feedback derived from the customer after delivery. In addition, the project manager adjusts the planned number of iterations required to complete the software.

与其他在软件交付时结束的流程模型不同,螺旋模型可以适应计算机软件的整个生命周期。螺旋模型是开发大型系统和软件的现实方法。它使用原型设计作为风险降低机制。螺旋模型要求直接考虑项目各个阶段的技术风险,如果应用得当,应该在风险出现问题之前将其降低。第30页

Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer software. The spiral model is a realistic approach to the development of large-scale systems and software. It uses prototyping as a risk reduction mechanism. The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic.Page 30

但与其他范式一样,螺旋模型也不是万能药。让客户(尤其是在合同情况下)相信渐进方法是可控的可能很困难。它需要大量的风险评估专业知识,并依赖这些专业知识来取得成功。如果重大风险不及时发现和管控,必然会出现问题。

But like other paradigms, the spiral model is not a panacea. It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur.

我们已经注意到,现代计算机软件的特点是不断变化、时间紧迫、迫切需要客户-用户满意度。在许多情况下,上市时间是最重要的管理要求。如果错过了市场窗口,软件项目本身可能就没有意义了。5

We have already noted that modern computer software is characterized by continual change, by very tight time lines, and by an emphatic need for customer-user satisfaction. In many cases, time to market is the most important management requirement. If a market window is missed, the software project itself may be meaningless.5

进化模型的目的是以迭代或增量的方式开发高质量的软件6 。然而,可以使用演进过程来强调灵活性、可扩展性和开发速度。软件团队及其经理面临的挑战是在这些关键项目和产品参数与客户满意度(软件质量的最终仲裁者)之间建立适当的平衡。第31页

The intent of evolutionary models is to develop high-quality software6 in an iterative or incremental manner. However, it is possible to use an evolutionary process to emphasize flexibility, extensibility, and speed of development. The challenge for software teams and their managers is to establish a proper balance between these critical project and product parameters and customer satisfaction (the ultimate arbiter of software quality).Page 31

2.5.4 统一过程模型

2.5.4 Unified Process Model

在某些方面,统一过程(UP)[Jac99]试图利用传统软件过程模型的最佳功能和特性,但以实现敏捷软件开发的许多最佳原则的方式来描述它们(第3章。统一流程认识到客户沟通和描述客户对系统的看法(用例)的简化方法的重要性。7它强调软件架构的重要作用,并“帮助架构师专注于正确的目标,例如可理解性、对未来变化的依赖和重用”[Jac99]。它提出了一个迭代和增量的流程,提供了现代软件开发中必不可少的进化感觉。第32页

In some ways the Unified Process (UP) [Jac99] is an attempt to draw on the best features and characteristics of traditional software process models but characterize them in a way that implements many of the best principles of agile software development (Chapter 3). The Unified Process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system (the use case).7 It emphasizes the important role of software architecture and “helps the architect focus on the right goals, such as understandability, reliance to future changes, and reuse” [Jac99]. It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modern software development.Page 32

UML(统一建模语言)是为了支持他们的工作而开发的。UML 包含用于面向对象系统的建模和开发的强大符号,并且已成为所有类型建模软件事实上的行业标准。本书第二部分通篇使用 UML 来表示需求和设计模型。附录 1 为那些不熟悉基本 UML 符号和建模规则的人提供了介绍性教程和推荐书籍列表。

UML, the unified modeling language, was developed to support their work. UML contains a robust notation for the modeling and development of object-oriented systems and has became a de facto industry standard for modeling software of all types. UML is used throughout Part Two of this book to represent both requirements and design models. Appendix 1 presents an introductory tutorial and a list of recommended books for those who are unfamiliar with basic UML notation and modeling rules.

图 2.6描述了统一过程的“阶段”,并将它们与第 2.1 节中讨论的通用活动联系起来。

Figure 2.6 depicts the “phases” of the Unified Process and relates them to the generic activities that were discussed in Section 2.1.

图2.6 统一流程

Figure 2.6 The Unified Process

UP 的初始阶段是进行客户沟通和规划的阶段。基本业务需求通过一组初步用例(第 7 章)进行描述,这些用例描述了每个主要用户类别希望在软件架构中实现的特性和功能。规划确定资源、评估主要风险并定义软件增量的初步时间表。第33页

The inception phase of the UP is where customer communication and planning takes place. Fundamental business requirements are described through a set of preliminary use cases (Chapter 7) that describe which features and functions each major class of users desires that will become realized in the software architecture. Planning identifies resources, assesses major risks, and defines a preliminary schedule for the software increments.Page 33

细化阶段包括通用流程模型的规划和建模活动(图 2.6)。细化细化和扩展了初步用例,并创建了一个体系结构基线,其中包括软件的五个不同视图——用例模型、分析模型、设计模型、实现模型和部署模型。8此时经常对计划进行修改。

The elaboration phase encompasses the planning and modeling activities of the generic process model (Figure 2.6). Elaboration refines and expands the preliminary use cases and creates an architectural baseline that includes five different views of the software—the use case model, the analysis model, the design model, the implementation model, and the deployment model.8 Modifications to the plan are often made at this time.

UP 的构建阶段与为通用软件过程定义的构建活动相同。然后,软件增量(即发布)的所有必要和必需的特性和功能都在源代码中实现。当组件被实现时,为每个组件设计并执行单元测试9 。此外,还进行集成活动(组件组装和集成测试)。用例用于派生一套验收测试,这些测试在下一个 UP 阶段开始之前执行。

The construction phase of the UP is identical to the construction activity defined for the generic software process. All necessary and required features and functions for the software increment (i.e., the release) are then implemented in source code. As components are being implemented, unit tests9 are designed and executed for each. In addition, integration activities (component assembly and integration testing) are conducted. Use cases are used to derive a suite of acceptance tests that are executed prior to the initiation of the next UP phase.

UP 的过渡阶段包括通用构建活动的后期阶段和通用部署(交付和反馈)活动的第一部分。软件和支持文档提供给最终用户进行 Beta 测试,用户反馈报告缺陷和必要的更改。在过渡阶段结束时,软件增量成为可用的软件版本。

The transition phase of the UP encompasses the latter stages of the generic construction activity and the first part of the generic deployment (delivery and feedback) activity. Software and supporting documentation is given to end users for beta testing, and user feedback reports both defects and necessary changes. At the conclusion of the transition phase, the software increment becomes a usable software release.

UP 的生产阶段与通用流程的部署活动一致在此阶段,将监视软件的持续使用,提供对操作环境(基础设施)的支持,并提交和评估缺陷报告和更改请求。

The production phase of the UP coincides with the deployment activity of the generic process. During this phase, the ongoing use of the software is monitored, support for the operating environment (infrastructure) is provided, and defect reports and requests for changes are submitted and evaluated.

在进行构建、过渡和生产阶段的同时,下一个软件增量的工作可能已经开始。这意味着五个 UP 阶段不是按顺序发生的,而是交错并发的。

It is likely that at the same time the construction, transition, and production phases are being conducted, work may have already begun on the next software increment. This means that the five UP phases do not occur in a sequence, but rather with staggered concurrency.

应该注意的是,并不是每个软件项目都会执行为 UP 工作流程确定的每个任务。团队调整流程(操作、任务、子任务和工作产品)以满足其需求。

It should be noted that not every task identified for a UP workflow is conducted for every software project. The team adapts the process (actions, tasks, subtasks, and work products) to meet its needs.

2.6 产品与工艺

2.6 Product and Process

表 2.1总结了我们讨论的流程模型的一些优点和缺点。在本书的前几版中,我们讨论了许多其他内容。现实情况是,没有一个流程对于每个项目都是完美的。通常,软件团队会采用 2.5 中讨论的一个或多个流程模型或第 3 章中讨论的敏捷流程模型来满足他们手头项目的需求。第34页

Some of the strengths and weaknesses of the process models we have discussed are summarized in Table 2.1. In previous editions of this book we have discussed many others. The reality is that no process is perfect for every project. Usually the software team adapts one or more of the process models discussed in 2.5 or the agile process models discussed in Chapter 3 to meet their needs for the project at hand.Page 34

如果过程薄弱,最终产品无疑会受到影响。但过分依赖流程也是危险的。在多年前写的一篇短文中,玛格丽特·戴维斯 [Dav95a] 对产品和流程的二元性做出了永恒的评论:

If the process is weak, the end product will undoubtedly suffer. But an obsessive overreliance on process is also dangerous. In a brief essay written many years ago, Margaret Davis [Dav95a] makes timeless comments on the duality of product and process:

大约每十年五年,软件社区就会重新定义“问题”,将焦点从产品问题转移到流程问题。。。。

About every ten years give or take five, the software community redefines “the problem” by shifting its focus from product issues to process issues. . . .

虽然钟摆的自然趋势是停在两个极端之间的中间点,但软件社区的焦点不断转移,因为当最后一次摆动失败时会施加新的力。这些波动本身是有害的,因为它们从根本上改变了执行工作的含义,让普通软件从业者感到困惑,更不用说出色地执行工作了。这些摇摆也不能解决“问题”,因为只要产品和流程被视为形成二分法而不是二元性,它们就注定会失败。

While the natural tendency of a pendulum is to come to rest at a point midway between two extremes, the software community’s focus constantly shifts because new force is applied when the last swing fails. These swings are harmful in and of themselves because they confuse the average software practitioner by radically changing what it means to perform the job let alone perform it well. The swings also do not solve “the problem” for they are doomed to fail as long as product and process are treated as forming a dichotomy instead of a duality.

。。。如果您仅将其视为一个过程或一个产品,您将永远无法推导出或理解完整的工件、其背景、用途、意义和价值。

. . . You can never derive or understand the full artifact, its context, use, meaning, and worth if you view it as only a process or only a product.

所有的人类活动可能都是一个过程,但我们每个人都从这些活动中获得了自我价值感,这些活动产生了可以使用或使用的表征或实例。第35页要么被多个人欣赏,要么被反复使用,要么在其他未考虑的情况下使用。也就是说,我们从自己或他人重复使用我们的产品中获得满足感。

All of human activity may be a process, but each of us derives a sense of self-worth from those activities that result in a representation or instance that can be used or Page 35appreciated either by more than one person, used over and over, or used in some other context not considered. That is, we derive feelings of satisfaction from reuse of our products by ourselves or others.

因此,虽然将重用目标快速融入软件开发可能会增加软件从业者从其工作中获得的满意度,但它也增加了接受产品和过程的二元性的紧迫性。。。。

Thus, while the rapid assimilation of reuse goals into software development potentially increases the satisfaction software practitioners derive from their work, it also increases the urgency for acceptance of the duality of product and process. . . .

人们从创作过程中获得的满足感与从最终产品中获得的满足感一样多(甚至更多)。艺术家喜欢画笔的笔触,就像喜欢框架的结果一样。作家喜欢寻找合适的隐喻,就像喜欢完成书一样。作为一名创意软件专业人士,您还应该从过程中获得与最终产品一样的满足感。随着软件工程的不断发展,产品和流程的二元性是保持创意人员参与的重要因素之一。

People derive as much (or more) satisfaction from the creative process as they do from the end product. An artist enjoys the brush strokes as much as the framed result. A writer enjoys the search for the proper metaphor as much as the finished book. As a creative software professional, you should also derive as much satisfaction from the process as the end product. The duality of product and process is one important element in keeping creative people engaged as software engineering continues to evolve.

2.7 总结

2.7 Summary

软件工程的通用过程模型包含一组框架和伞式活动、操作和工作任务。各种过程模型中的每一个都可以通过不同的过程流来描述,即框架活动、操作和任务如何按顺序和时间顺序组织的描述。过程模式可用于解决软件过程中遇到的常见问题。

A generic process model for software engineering encompasses a set of framework and umbrella activities, actions, and work tasks. Each of a variety of process models can be described by a different process flow—a description of how the framework activities, actions, and tasks are organized sequentially and chronologically. Process patterns can be used to solve common problems that are encountered as part of the software process.

规范性过程模型已被应用多年,旨在为软件开发带来秩序和结构。这些模型中的每一个都提出了稍微不同的流程,但都执行相同的一组通用框架活动:通信、规划、建模、构建和部署。

Prescriptive process models have been applied for many years in an effort to bring order and structure to software development. Each of these models suggests a somewhat different process flow, but all perform the same set of generic framework activities: communication, planning, modeling, construction, and deployment.

顺序过程模型,例如瀑布模型,是最古老的软件工程范例。他们提出的线性流程通常与软件世界中的现代现实(例如,持续变化、不断发展的系统、紧迫的时间线)不一致。然而,它们确实适用于需求定义明确且稳定的情况。

Sequential process models, such as the waterfall model, are the oldest software engineering paradigms. They suggest a linear process flow that is often inconsistent with modern realities (e.g., continuous change, evolving systems, tight time lines) in the software world. They do, however, have applicability in situations where requirements are well defined and stable.

增量过程模型本质上是迭代的,并且可以非常快速地生成软件的工作版本。演化过程模型认识到大多数软件工程项目的迭代、增量性质,并旨在适应变化。进化模型,例如原型设计和螺旋模型,可以快速生成增量工作产品(或软件的工作版本)。这些模型可以应用于所有软件工程活动——从概念开发到长期系统维护。

Incremental process models are iterative in nature and produce working versions of software quite rapidly. Evolutionary process models recognize the iterative, incremental nature of most software engineering projects and are designed to accommodate change. Evolutionary models, such as prototyping and the spiral model, produce incremental work products (or working versions of the software) quickly. These models can be adopted to apply across all software engineering activities—from concept development to long-term system maintenance.

统一流程是一个“用例驱动、以体系结构为中心、迭代和增量”的软件流程,被设计为 UML 方法和工具的框架。

The Unified Process is a “use case driven, architecture-centric, iterative and incremental” software process designed as a framework for UML methods and tools.

问题与思考点

Problems and Points to Ponder

2.1. Baetjer [Bae98] 指出:“该过程提供了用户和设计者之间、用户和不断发展的工具之间以及设计者和不断发展的工具[技术]之间的交互。” 列出五个问题:(1) 设计者应该问用户,(2) 用户应该问设计者,(3) 用户应该问自己要构建的软件产品,(4) 设计者应该问自己关于要构建的软件产品。要构建的内容以及构建它的过程。

2.1. Baetjer [Bae98] notes: “The process provides interaction between users and designers, between users and evolving tools, and between designers and evolving tools [technology].” List five questions that (1) designers should ask users, (2) users should ask designers, (3) users should ask themselves about the software product that is to be built, and (4) designers should ask themselves about the software product that is to be built and the process that will be used to build it.

第36页2.2. 讨论第 2.1 节中描述的各种流程之间的差异。确定可能适用于所描述的每个通用流程的问题类型。

Page 362.2. Discuss the differences among the various process flows described in Section 2.1. Identify the types of problems that might be applicable to each of the generic flows described.

2.3. 尝试为沟通活动制定一套行动。选择一个操作,并为其定义一组任务。

2.3. Try to develop a set of actions for the communication activity. Select one action, and define a task set for it.

2.4. 当您遇到两个利益相关者对于软件应该是什么有冲突的想法时,沟通过程中的一个常见问题就会出现。也就是说,它们具有相互冲突的要求。开发解决此问题的流程模式并提出有效的解决方法。

2.4. A common problem during communication occurs when you encounter two stakeholders who have conflicting ideas about what the software should be. That is, they have mutually conflicting requirements. Develop a process pattern that addresses this problem and suggest an effective approach to it.

2.5. 提供三个适合瀑布模型的软件项目示例。请明确点。

2.5. Provide three examples of software projects that would be amenable to the waterfall model. Be specific.

2.6。提供三个适合原型模型的软件项目示例。请明确点。

2.6. Provide three examples of software projects that would be amenable to the prototyping model. Be specific.

2.7. 当您沿着螺旋流程向外移动时,您对正在开发或维护的软件有什么看法?

2.7. As you move outward along the spiral process flow, what can you say about the software that is being developed or maintained?

2.8. 是否可以组合流程模型?如果是这样,请提供一个例子。

2.8. Is it possible to combine process models? If so, provide an example.

2.9. 开发质量“足够好”的软件有哪些优点和缺点?也就是说,当我们强调开发速度而不是产品质量时会发生什么?

2.9. What are the advantages and disadvantages of developing software in which quality is “good enough”? That is, what happens when we emphasize development speed over product quality?

2.10. 有可能证明一个软件组件甚至整个程序都是正确的吗?那么为什么不是每个人都这样做呢?

2.10. It is possible to prove that a software component and even an entire program is correct? So why doesn’t everyone do this?

2.11. 统一过程和UML是一回事吗?解释你的答案。

2.11. Are the Unified Process and UML the same thing? Explain your answer.

1 SEI 的 CMMI-DEV [CMM07] 详细描述了软件流程的特征以及成功流程的标准。

1 The SEI’s CMMI-DEV [CMM07] describes the characteristics of a software process and the criteria for a successful process in voluminous detail.

2规范性流程模型有时被称为“传统”流程模型。

2 Prescriptive process models are sometimes referred to as “traditional” process models.

3尽管 Winston Royce [Roy70] 提出的原始瀑布模型提供了“反馈循环”,但应用此流程模型的绝大多数组织将其视为严格线性的。

3 Although the original waterfall model proposed by Winston Royce [Roy70] made provision for “feedback loops,” the vast majority of organizations that apply this process model treat it as if it were strictly linear.

4本节讨论的螺旋模型是 Boehm 提出的模型的变体。有关原始螺旋模型的更多信息,请参阅 [Boe88]。关于 Boehm 螺旋模型的更多最新讨论可以在 [Boe98] 和 [Boe01a] 中找到。

4 The spiral model discussed in this section is a variation on the model proposed by Boehm. For further information on the original spiral model, see [Boe88]. More recent discussion of Boehm’s spiral model can be found in [Boe98] and [Boe01a].

5然而,值得注意的是,率先进入市场并不能保证成功。事实上,许多非常成功的软件产品都是第二甚至第三进入市场的(从前辈的错误中吸取教训)。

5 It is important to note, however, that being the first to reach a market is no guarantee of success. In fact, many very successful software products have been second or even third to reach the market (learning from the mistakes of their predecessors).

6在这种情况下,软件质量的定义相当广泛,不仅包括客户满意度,还包括本书第二部分讨论的各种技术标准。

6 In this context, software quality is defined quite broadly to encompass not only customer satisfaction, but also a variety of technical criteria discussed in Part Two of this book.

7(第 7 章)是从用户角度描述系统功能或特性的文本叙述或模板。用例由用户编写,并作为创建更全面的分析模型的基础。

7 A use case (Chapter 7) is a text narrative or template that describes a system function or feature from the user’s point of view. A use case is written by the user and serves as a basis for the creation of a more comprehensive analysis model.

8值得注意的是,架构基线不是原型,因为它不会被丢弃。相反,基线会在下一个 UP 阶段得到充实。

8 It is important to note that the architectural baseline is not a prototype in that it is not thrown away. Rather, the baseline is fleshed out during the next UP phase.

9第 19 章至第 21 章对软件测试(包括单元测试)进行了全面讨论。

9 A comprehensive discussion of software testing (including unit tests) is presented in Chapters 19 through 21).

第37页

Page 37

章节

chapter

3敏捷性和流程

3 Agility and Process

2001 年,一群著名的软件开发人员、作家和顾问 [Bec01] 签署了“敏捷软件开发宣言”,其中他们主张“个人和交互胜过流程和工具,工作软件胜过全面的文档,客户协作”优先于合同谈判,响应变化优先于遵循计划。”

In 2001, a group of noted software developers, writers, and consultants [Bec01] signed the “Manifesto for Agile Software Development” in which they argued in favor of “individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.”

第38页指导敏捷开发的基本思想导致了敏捷1方法的开发,旨在克服传统软件工程中感知到的和实际的弱点。敏捷开发可以提供重要的好处,但它可能并不适用于所有项目、所有产品、所有人和所有情况。它也与扎实的软件工程实践并不对立,并且可以作为所有软件工作的压倒一切的哲学。

Page 38The underlying ideas that guide agile development led to the development of agile1 methods designed to overcome perceived and actual weaknesses in conventional software engineering. Agile development can provide important benefits, but it may not be applicable to all projects, all products, all people, and all situations. It is also not antithetical to solid software engineering practice and can be applied as an overriding philosophy for all software work.

在现代经济中,通常很难或不可能预测基于计算机的系统(例如,移动应用程序)将如何随着时间的推移而发展。市场状况瞬息万变,最终用户需求不断变化,新的竞争威胁毫无预警地出现。在许多情况下,您无法在项目开始之前完全定义需求。您必须足够敏捷才能应对不断变化的业务环境。

In the modern economy, it is often difficult or impossible to predict how a computer-based system (e.g., a mobile application) will evolve as time passes. Market conditions change rapidly, end-user needs evolve, and new competitive threats emerge without warning. In many situations, you won’t be able to define requirements fully before the project begins. You must be agile enough to respond to a fluid business environment.

流动性意味着变化,而变化的代价是昂贵的——尤其是在不受控制或管理不善的情况下。敏捷方法最引人注目的特征之一是它能够通过软件流程降低变更成本。

Fluidity implies change, and change is expensive—particularly if it is uncontrolled or poorly managed. One of the most compelling characteristics of the agile approach is its ability to reduce the costs of change through the software process.

在一本关于敏捷软件开发的发人深省的书中,Alistair Cockburn [Coc02] 认为,第 2 章中介绍的规范性流程模型有一个重大缺陷:它们忘记了构建计算机软件的人的弱点。软件工程师不是机器人。他们的工作风格差异很大,在技能水平、创造力、有序性、一致性和自发性方面也存在显着差异。有些人能够很好地以书面形式进行沟通,而另一些人则不然。如果流程模型要发挥作用,它们必须提供一种现实的机制来鼓励必要的纪律,或者它们必须以对从事软件工程工作的人员表现出“宽容”的方式进行描述。

In a thought-provoking book on agile software development, Alistair Cockburn [Coc02] argues that the prescriptive process models introduced in Chapter 2 have a major failing: they forget the frailties of the people who build computer software. Software engineers are not robots. They exhibit great variation in working styles and significant differences in skill level, creativity, orderliness, consistency, and spontaneity. Some communicate well in written form, others do not. If process models are to work, they must provide a realistic mechanism for encouraging the discipline that is necessary, or they must be characterized in a manner that shows “tolerance” for the people who do software engineering work.

3.1 什么是敏捷性?

3.1 What Is Agility?

软件工程工作中的敏捷性到底是什么?Ivar Jacobson [Jac02a] 认为,变革的普遍性是敏捷性的主要驱动力。如果软件工程师要适应雅各布森所描述的快速变化,他们就必须快速行动。

Just what is agility in the context of software engineering work? Ivar Jacobson [Jac02a] argues that the pervasiveness of change is the primary driver for agility. Software engineers must be quick on their feet if they are to accommodate the rapid changes that Jacobson describes.

但敏捷性不仅仅是对变化的有效响应。它还包含本章开头提到的宣言中所拥护的哲学。它鼓励团队结构和态度,使沟通(团队成员之间、技术人员和业务人员之间、软件工程师和经理之间)更加轻松。它强调操作软件的快速交付,而淡化中间工作产品的重要性(并不总是一件好事);它将客户作为开发团队的一部分,努力消除许多软件项目中持续存在的“我们和他们”的态度;它认识到在不确定的世界中进行规划有其局限性,并且项目计划必须具有灵活性。第39页

But agility is more than an effective response to change. It also encompasses the philosophy espoused in the manifesto noted at the beginning of this chapter. It encourages team structures and attitudes that make communication (among team members, between technologists and business people, and between software engineers and their managers) more facile. It emphasizes rapid delivery of operational software and deemphasizes the importance of intermediate work products (not always a good thing); it adopts the customer as a part of the development team and works to eliminate the “us and them” attitude that continues to pervade many software projects; it recognizes that planning in an uncertain world has its limits and that a project plan must be flexible.Page 39

敏捷性可以应用于任何软件流程。然而,为了实现这一目标,流程的设计方式必须允许项目团队调整任务并简化它们,以了解敏捷开发方法的流动性的方式进行规划,消除除最重要的之外的所有内容。重要的工作产品并保持精益,并强调增量交付策略,根据产品类型和操作环境尽快将工作软件交付给客户。

Agility can be applied to any software process. However, to accomplish this, it is essential that the process be designed in a way that allows the project team to adapt tasks and to streamline them, conduct planning in a way that understands the fluidity of an agile development approach, eliminate all but the most essential work products and keep them lean, and emphasize an incremental delivery strategy that gets working software to the customer as rapidly as feasible for the product type and operational environment.

3.2 敏捷性和变革成本

3.2 Agility and the Cost of Change

软件开发中的传统观点(由数十年的经验支持)是,随着项目的进展,变更成本呈非线性增加(图 3.1,黑色实线)。当软件团队收集需求(在项目早期)时,适应变更相对容易。可能需要修改使用场景,扩展功能列表,或者编辑书面规范。完成这项工作的成本是最低的,并且所需的时间不会对项目的结果产生不利影响。但如果我们快进几个月呢?团队正在进行验证测试(这在项目中相对较晚发生),并且一个重要的利益相关者正在请求重大的功能更改。该变更需要修改软件的架构设计、三个新组件的设计和构建、另外五个组件的修改、新测试的设计等等。成本迅速上升,并且确保做出改变而不会产生意想不到的副作用所需的时间和精力是不小的。第 40 页

The conventional wisdom in software development (supported by decades of experience) is that the cost of change increases nonlinearly as a project progresses (Figure 3.1, solid black curve). It is relatively easy to accommodate a change when a software team is gathering requirements (early in a project). A usage scenario might have to be modified, a list of functions may be extended, or a written specification can be edited. The costs of doing this work are minimal, and the time required will not adversely affect the outcome of the project. But what if we fast-forward a number of months? The team is in the middle of validation testing (something that occurs relatively late in the project), and an important stakeholder is requesting a major functional change. The change requires a modification to the architectural design of the software, the design and construction of three new components, modifications to another five components, the design of new tests, and so on. Costs escalate quickly, and the time and effort required to ensure that the change is made without unintended side effects are nontrivial.Page 40

敏捷性的支持者(例如,[Bec99]、[Amb04])认为,精心设计的敏捷流程“压平”变更成本曲线(图 3.1,阴影实线曲线),允许软件团队在后期适应变更。软件项目不会对成本和时间造成巨大影响。您已经了解到敏捷流程包含增量交付。当增量交付与其他敏捷实践(例如连续单元测试和结对编程)( 第 20 章中简要讨论)相结合时,进行更改的成本就会降低。尽管关于成本曲线平坦化程度的争论仍在继续,但有证据 [Coc01a] 表明可以实现变革成本的显着降低。

Proponents of agility (e.g., [Bec99], [Amb04]) argue that a well-designed agile process “flattens” the cost of change curve (Figure 3.1, shaded, solid curve), allowing a software team to accommodate changes late in a software project without dramatic cost and time impact. You’ve already learned that the agile process encompasses incremental delivery. When incremental delivery is coupled with other agile practices such as continuous unit testing and pair programming (discussed briefly in Chapter 20), the cost of making a change is attenuated. Although debate about the degree to which the cost curve flattens is ongoing, there is evidence [Coc01a] to suggest that a significant reduction in the cost of change can be achieved.

3.1变更成本与 开发时间的关系

Figure 3.1 Change costs as a function of time in development

3.3 什么是敏捷过程?

3.3 What Is an Agile Process?

任何敏捷软件流程的特征都满足关于大多数软件项目的许多关键假设 [Fow02]:

Any agile software process is characterized in a manner that addresses a number of key assumptions [Fow02] about the majority of software projects:

  1. 很难提前预测哪些软件需求将持续存在以及哪些将发生变化。随着项目的进展,预测客户优先级将如何变化同样困难。

  2. It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds.

  3. 对于许多类型的软件,设计和构建是交叉的。也就是说,这两项活动应该同时进行,以便设计模型在创建时得到验证。在使用施工来证明设计之前,很难预测需要多少设计。

  4. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design.

  5. 分析、设计、构建和测试并不像我们希望的那样可预测(从规划的角度来看)。

  6. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.

考虑到这三个假设,一个重要的问题出现了:我们如何创建一个可以管理不可预测性的流程?正如我们已经指出的,答案在于流程适应性(针对快速变化的项目和技术条件)。因此,敏捷流程必须具有适应性。

Given these three assumptions, an important question arises: How do we create a process that can manage unpredictability? The answer, as we have already noted, lies in process adaptability (to rapidly changing project and technical conditions). An agile process, therefore, must be adaptable.

但如果没有进步,持续的适应收效甚微。因此,敏捷软件流程必须逐步适应。为了实现增量适应,敏捷团队需要客户反馈(以便做出适当的适应)。客户反馈的有效催化剂是操作原型或操作系统的一部分。因此,应制定增量发展战略。软件增量(可执行原型或操作系统的一部分)必须在短时间内交付,以便适应与变化保持同步(不可预测性)。这种迭代方法使客户能够定期评估软件增量,向软件团队提供必要的反馈,并影响为适应反馈而进行的流程调整。

But continual adaptation without forward progress accomplishes little. Therefore, an agile software process must adapt incrementally. To accomplish incremental adaptation, an agile team requires customer feedback (so that the appropriate adaptations can be made). An effective catalyst for customer feedback is an operational prototype or a portion of an operational system. Hence, an incremental development strategy should be instituted. Software increments (executable prototypes or portions of an operational system) must be delivered in short time periods so that adaptation keeps pace with change (unpredictability). This iterative approach enables the customer to evaluate the software increment regularly, provide necessary feedback to the software team, and influence the process adaptations that are made to accommodate the feedback.

3.3.1 敏捷性原则

3.3.1 Agility Principles

敏捷联盟 [Agi17] 2为那些想要实现敏捷性的软件组织定义了 12 条原则。以下段落总结了这些原则。

The Agile Alliance [Agi17]2 defines 12 principles for those software organizations that want to achieve agility. These principles are summarized in the paragraphs that follow.

通过尽快交付给客户的软件提供价值来实现客户满意度。为了实现这一目标,敏捷开发人员认识到需求会发生变化。他们经常交付软件增量,并与所有利益相关者合作,以便对交付的反馈快速且有意义。第 41 页

Customer satisfaction is achieved by providing value through software that is delivered to the customer as rapidly as possible. To achieve this, agile developers recognize that requirements will change. They deliver software increments frequently and work together with all stakeholders so that feedback on their deliveries is rapid and meaningful.Page 41

敏捷团队由积极进取的个人组成,他们面对面沟通,并在有利于高质量软件开发的环境中工作。该团队遵循鼓励卓越技术和良好设计的流程,强调简单性——“最大化未完成工作量的艺术”[Agi17]。满足客户需求的可用软件是他们的首要目标,团队工作的节奏和方向必须是“可持续的”,使他们能够长时间有效地工作。

An agile team is populated by motivated individuals, who communicate face-to face and work in an environment that is conducive to high quality software development. The team follows a process that encourages technical excellence and good design, emphasizing simplicity—“the art of maximized the amount of work not done” [Agi17]. Working software that meets customer needs is their primary goal, and the pace and direction of the team’s work must be “sustainable,” enabling them to work effectively for long periods of time.

敏捷团队是一个“自组织团队”——可以开发结构良好的架构,从而实现可靠的设计和客户满意度。团队文化的一部分是反思性地考虑其工作,始终以改进实现其主要目标的方式为目的。

An agile team is a “self-organizing team”—one that can develop well-structured architectures that lead to solid designs and customer satisfaction. Part of the team culture is to consider its work introspectively, always with the intent of improving the manner in which it addresses its primary goal.

并非每个敏捷过程模型都同等重视地应用本节中描述的特征,并且某些模型选择忽略(或至少淡化)一个或多个敏捷原则的重要性。然而,这些原则定义了本章介绍的每个流程模型中维护的敏捷精神。

Not every agile process model applies characteristics described in this section with equal weight, and some models choose to ignore (or at least downplay) the importance of one or more agile principles. However, these principles define an agile spirit that is maintained in each of the process models presented in this chapter.

3.3.2 敏捷开发的政治

3.3.2 The Politics of Agile Development

关于敏捷软件开发相对于更传统的软件工程流程的好处和适用性,存在相当多的争论(有时是激烈的)。Jim Highsmith [Hig02a](滑稽地)在描述支持敏捷阵营(“敏捷主义者”)的感受时表述了极端的观点:“传统方法学家是一群墨守成规的人,他们宁愿生成完美的文档,也不愿提供完美的文档。”满足业务需求的工作系统。” 作为对比,他(再次,滑稽地)陈述了传统软件工程阵营的立场:“轻量级,呃,‘敏捷’方法论者是一群被美化的黑客,当他们尝试时,他们将会大吃一惊。将他们的玩具扩展到企业范围的软件。”

There is considerable debate (sometimes strident) about the benefits and applicability of agile software development as opposed to more conventional software engineering processes. Jim Highsmith [Hig02a] (facetiously) states the extremes when he characterizes the feeling of the pro-agility camp (“agilists”): “Traditional methodologists are a bunch of stick-in-the-muds who’d rather produce flawless documentation than a working system that meets business needs.” As a counterpoint, he states (again, facetiously) the position of the traditional software engineering camp: “Lightweight, er, ‘agile’ methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise when they try to scale up their toys into enterprise-wide software.”

与所有软件技术争论一样,这种方法论争论有可能退化为宗教战争。如果战争爆发,理性思维就会消失,决策将由信念而不是事实来指导。

Like all software technology arguments, this methodology debate risks degenerating into a religious war. If warfare breaks out, rational thought disappears and beliefs rather than facts guide decision making.

没有人反对敏捷性。真正的问题是:实现这一目标的最佳方法是什么?请记住,可用的软件很重要,但不要忘记它还必须表现出各种质量属性,包括可靠性、可用性和可维护性。如何构建能够满足客户当前需求并展现出使其能够扩展和扩展以满足客户长期需求的质量特征的软件?

No one is against agility. The real question is: What is the best way to achieve it? Keep in mind that working software is important, but don’t forget that it must also exhibit a variety of quality attributes including reliability, usability, and maintainability. How do you build software that meets customers’ needs today and exhibits the quality characteristics that will enable it to be extended and scaled to meet customers’ needs over the long term?

这些问题都没有绝对的答案。即使在敏捷学派内部,也提出了许多框架模型(第 3.4 节第 3.5 节),每个框架模型都对敏捷性问题采取了略有不同的方法。每个模型中都有一组“想法”(敏捷主义者不愿意称它们为“工作任务”),它们代表了与传统软件工程的重大背离。然而,许多敏捷概念只是优秀软件工程概念的改编。底线是,考虑两所学校的优点可以得到很多好处,而诋毁任何一种方法几乎都没有什么好处。

There are no absolute answers to either of these questions. Even within the agile school itself, there are many proposed framework models (Sections 3.4 and 3.5), each with a subtly different approach to the agility problem. Within each model there is a set of “ideas” (agilists are loath to call them “work tasks”) that represent a significant departure from traditional software engineering. And yet, many agile concepts are simply adaptations of good software engineering concepts. The bottom line is there is much that can be gained by considering the best of both schools and virtually nothing to be gained by denigrating either approach.

第42页

Page 42

3.4 敏捷

3.4 Scrum

Scrum(该名称源自橄榄球比赛期间发生的一项活动)3是一种非常流行的敏捷软件开发方法,由 Jeff Sutherland 和他的开发团队在 20 世纪 90 年代初构想出来。Schwaber 和 Beedle [Sch01b] 对 Scrum 方法进行了进一步开发。

Scrum (the name is derived from an activity that occurs during a rugby match)3 is a very popular agile software development method that was conceived by Jeff Sutherland and his development team in the early 1990s. Further development on the Scrum methods was performed by Schwaber and Beedle [Sch01b].

Scrum 原则与敏捷宣言一致,用于指导包含以下框架活动的流程中的开发活动:需求、分析、设计、演进和交付。在每个框架活动中,工作任务发生在相对较短的时间盒内的4 个周期(称为冲刺)中。在冲刺中进行的工作(每个框架活动所需的冲刺数量将根据产品的规模及其复杂性而变化)适应手头的问题,并由 Scrum 团队实时定义和经常修改。Scrum 流程的整体流程如图 3.2所示。我们对 Scrum 框架的大部分描述都出现在 Fowler 和 Sutherland [Fow16] 中。5第 43 页

Scrum principles are consistent with the agile manifesto and are used to guide development activities within a process that incorporates the following framework activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks take place in a relatively short time-boxed4 period called a sprint. The work conducted within a sprint (the number of sprints required for each framework activity will vary depending on size of the product and its complexity) is adapted to the problem at hand and is defined and often modified in real time by the Scrum team. The overall flow of the Scrum process is illustrated in Figure 3.2. Much of our description of the Scrum framework appears in Fowler and Sutherland [Fow16].5Page 43

图3.2 Scrum 流程

Figure 3.2 Scrum process flow

3.4.1 Scrum 团队和工件

3.4.1 Scrum Teams and Artifacts

Scrum 团队是一个自组织的跨学科团队,由一名产品负责人、一名Scrum Master和一个小型(三到六人)开发团队组成。主要的 Scrum 工件是产品待办事项冲刺待办事项和代码增量。开发过程中,将项目分为一系列增量原型开发周期,长度为 2 至 4 周,称为冲刺 (sprint)第 44 页

The Scrum team is a self-organizing interdisciplinary team consisting of a product owner, a Scrum master, and a small (three to six people) development team. The principle Scrum artifacts are the product backlog, the sprint backlog, and the code increment. Development proceeds by breaking the project into a series of incremental prototype development periods 2 to 4 weeks in length called sprints.Page 44

产品待办事项列表是为客户提供业务价值的产品需求或功能的优先级列表。经产品负责人批准并征得开发团队同意后,可以随时将项目添加到待办事项列表中。产品负责人订购产品待办事项中的项目,以满足所有利益相关者最重要的目标。当产品不断发展以满足利益相关者的需求时,产品待办事项列表永远不会完成。产品负责人是唯一决定是否提前结束冲刺或在不接受增量的情况下延长冲刺的人。

The product backlog is a prioritized list of product requirements or features that provide business value for the customer. Items can be added to the backlog at any time with the approval of the product owner and the consent of the development team. The product owner orders the items in the product backlog to meet the most important goals of all stakeholders. The product backlog is never complete while the product is evolving to meet stakeholder needs. The product owner is the only person who decides whether to end a sprint prematurely or extend the sprint if the increment is not accepted.

冲刺待办事项是产品团队选择的产品待办事项的子集,要在当前活动冲刺期间作为代码增量完成。增量是先前冲刺中完成的所有产品积压项目和当前冲刺中要完成的所有积压项目的并集。开发团队创建一个计划来交付软件增量,其中包含旨在满足当前冲刺中与产品负责人协商的重要目标的选定功能。大多数冲刺都有时间限制,在 3 到 4 周内完成。开发团队如何完成增量由团队决定。开发团队还决定增量何时完成并准备好向产品负责人演示。除非取消并重新启动冲刺,否则无法将新功能添加到冲刺待办事项中。

The sprint backlog is the subset of product backlog items selected by the product team to be completed as the code increment during the current active sprint. The increment is the union of all product backlog items completed in previous sprints and all backlog items to be completed in the current sprints. The development team creates a plan for delivering a software increment containing the selected features intended to meet an important goal as negotiated with the product owner in the current sprint. Most sprints are time-boxed to be completed in 3 to 4 weeks. How the development team completes the increment is left up to the team to decide. The development team also decides when the increment is done and ready to demonstrate to the product owner. No new features can be added to the sprint backlog unless the sprint is cancelled and restarted.

Scrum Master 充当 Scrum 团队所有成员的促进者。她主持每日 Scrum 会议,并负责消除团队成员在会议期间发现的障碍。她指导开发团队成员在有时间的情况下互相帮助完成冲刺任务。她帮助产品负责人找到管理产品待办事项列表项目的技术,并帮助确保以清晰简洁的方式表述待办事项列表项目。

The Scrum master serves as facilitator to all members of the Scrum team. She runs the daily Scrum meeting and is responsible for removing obstacles identified by team members during the meeting. She coaches the development team members to help each other complete sprint tasks when they have time available. She helps the product owner find techniques for managing the product backlog items and helps ensure that backlog items are stated in clear and concise terms.

3.4.2 Sprint计划会议

3.4.2 Sprint Planning Meeting

在开始之前,任何开发团队都会与产品所有者和所有其他利益相关者合作开发产品待办事项中的项目。第 7 章讨论了收集这些需求的技术。产品所有者和开发团队根据所有者业务需求的重要性以及完成每个项目所需的软件工程任务(编程和测试)的复杂性,对产品待办事项中的项目进行排名。有时,这会导致识别出向最终用户提供所需功能所需的缺失特性。

Prior to beginning, any development team works with the product owner and all other stakeholders to develop the items in the product backlog. Techniques for gathering these requirements are discussed in Chapter 7. The product owner and the development team rank the items in the product backlog by the importance of the owner’s business needs and the complexity of the software engineering tasks (programming and testing) required to complete each of them. Sometimes this results in the identification of missing features needed to deliver the required functionality to the end users.

在开始每个冲刺之前,产品负责人都会陈述她在即将到来的冲刺中完成的增量的开发目标。Scrum 管理员和开发团队选择要移至冲刺待办事项列表的项目。开发团队确定在分配给冲刺的时间范围内增量可以交付什么,以及通过 Scrum Master 确定交付增量需要哪些工作。开发团队决定需要哪些角色以及如何填补这些角色。

Prior to starting each sprint, the product owner states her development goal for the increment to be completed in the upcoming sprint. The Scrum master and the development team select the items to move from to the sprint backlog. The development team determines what can be delivered in the increment within the constraints of the time-box allocated for the sprint and, with the Scrum master, what work will be needed to deliver the increment. The development team decides which roles are needed and how they will need to be filled.

3.4.3 每日 Scrum 会议

3.4.3 Daily Scrum Meeting

每日 Scrum 会议是安排在每个工作日开始时的 15 分钟活动,以便团队成员同步他们的活动并制定接下来 24 小时的计划。Scrum Master 和开发团队始终参加每日 Scrum。有些团队允许产品负责人偶尔参加。第45页

The daily Scrum meeting is a 15-minute event scheduled at the start of each workday to allow team members to synchronize their activities and make plans for the next 24 hours. The Scrum master and the development team always attend the daily Scrum. Some teams allow the product owner to attend occasionally.Page 45

所有团队成员都会提出并回答三个关键问题:

Three key questions are asked and answered by all team members:

  • 自上次团队会议以来您做了什么?

  • What did you do since the last team meeting?

  • 您遇到什么障碍?

  • What obstacles are you encountering?

  • 您计划在下次团队会议之前完成什么任务?

  • What do you plan to accomplish by the next team meeting?

Scrum Master 主持会议并评估每个人的反应。Scrum会议可以帮助团队尽早发现潜在的问题。如果可能的话,Scrum Master 的任务是在下一次 Scrum 会议之前清除出现的障碍。这些会议不是解决问题的会议,而是在线下举行的,并且只涉及受影响的各方。此外,这些日常会议会导致“知识社会化”[Bee99],从而促进自组织的团队结构。

The Scrum master leads the meeting and assesses the responses from each person. The Scrum meeting helps the team to uncover potential problems as early as possible. It is the Scrum master’s task to clear obstacles presented before the next Scrum meeting if possible. These are not problem-solving meetings, those occur off-line and only involve the affected parties. Also, these daily meetings lead to “knowledge socialization” [Bee99] and thereby promote a self-organizing team structure.

一些团队使用这些会议来宣布冲刺积压项目已完成或完成。当团队认为所有冲刺积压项目已完成时,团队可能会决定安排演示并与产品负责人一起审查已完成的增量。

Some teams use these meetings to declare sprint backlog items complete or done. When the team considers all sprint backlog items complete, the team may decide to schedule a demo and review of the completed increment with the product owner.

3.4.4 Sprint评审会议

3.4.4 Sprint Review Meeting

当开发团队判断增量已完成时,冲刺评审发生在冲刺结束时。冲刺评审通常会在 4 周的冲刺中举行 4 小时的会议。Scrum Master、开发团队、产品所有者和选定的利益相关者参加此审核。主要活动是演示冲刺期间完成的软件增量。值得注意的是,演示可能不包含所有计划的功能,而是包含那些要在为冲刺定义的时间范围内交付的功能。

The sprint review occurs at the end of the sprint when the development team has judged the increment complete. The sprint review is often time-boxed as a 4-hour meeting for a 4-week sprint. The Scrum master, the development team, the product owner, and selected stakeholders attend this review. The primary activity is a demo of the software increment completed during the sprint. It is important to note that the demo may not contain all planned functionality, but rather those functions that were to be delivered within the time-box defined for the sprint.

产品负责人可以接受增量是否完整。如果不被接受,产品负责人和利益相关者会提供反馈,以便进行新一轮的冲刺计划。此时可能会在产品待办事项列表中添加或删除新功能。新功能可能会影响下一个冲刺中开发的增量的性质。

The product owner may accept the increment as complete or not. If it is not accepted, the product owner and the stakeholders provide feedback to allow a new round of sprint planning to take place. This is the time when new features may be added or removed from the product backlog. The new features may affect the nature of the increment developed in the next sprint.

3.4.5 Sprint 回顾

3.4.5 Sprint Retrospective

理想情况下,在开始另一次冲刺计划会议之前,Scrum Master 将与开发团队安排一次 3 小时的会议(对于为期 4 周的冲刺),称为冲刺回顾。在这次会议期间,团队讨论:

Ideally, before beginning another sprint planning meeting, the Scrum master will schedule a 3-hour meeting (for a 4-week sprint) with the development team called a sprint retrospective. During this meeting the team discusses:

  • 冲刺中哪些进展顺利

  • What went well in the sprint

  • 有什么可以改进的地方

  • What could be improved

  • 团队将在下一个冲刺中致力于改进什么

  • What the team will commit to improving in the next sprint

Scrum Master 主持会议并鼓励团队改进其开发实践,以便在下一个冲刺中变得更加有效。该团队计划通过调整“完成”的定义来提高产品质量。在这次会议结束时,团队应该对下一个冲刺所需的改进有一个很好的了解,并准备好在下一个冲刺计划会议上计划增量。

The Scrum master leads the meeting and encourages the team to improve its development practices to become more effective for the next sprint. The team plans ways to improve product quality by adapting its definition of “done.” At the end of this meeting, the team should have a good idea about the improvements needed in the next sprint and be ready to plan the increment at the next sprint planning meeting.

第46页

Page 46

3.5 其他敏捷框架

3.5 Other Agile Frameworks

软件工程的历史充斥着许多过时的过程描述和方法、建模方法和符号、工具和技术。每一个都声名狼藉,然后又被一些新的、(据称)更好的东西所掩盖。随着各种敏捷过程框架的引入(每个框架都在软件开发社区中争夺接受度),敏捷运动也遵循了相同的历史路径。6

The history of software engineering is littered with dozens of obsolete process descriptions and methodologies, modeling methods and notations, tools, and technology. Each flared in notoriety and was then eclipsed by something new and (purportedly) better. With the introduction of a wide array of agile process frameworks—each contending for acceptance within the software development community—the agile movement has followed the same historical path.6

正如我们在上一节中提到的,Scrum 是所有敏捷框架中使用最广泛的框架之一。但许多其他敏捷框架已经被提出并在整个行业中使用。在本节中,我们将简要概述三种流行的敏捷方法:极限编程 (XP)、看板和 DevOps。

As we noted in the last section, one of the most widely used of all agile frameworks is Scrum. But many other agile frameworks have been proposed and are in use across the industry. In this section, we present a brief overview of three popular agile methods: Extreme Programming (XP), Kanban, and DevOps.

3.5.1 XP 框架

3.5.1 The XP Framework

在本节中,我们简要概述极限编程(XP),这是最广泛使用的敏捷软件开发方法之一。Kent Beck [Bec04a] 撰写了有关 XP 的开创性著作。

In this section we provide a brief overview of Extreme Programming (XP), one of the most widely used approaches to agile software development. Kent Beck [Bec04a] wrote the seminal work on XP.

极限编程包含在四个框架活动的背景下发生的一组规则和实践:规划、设计、编码和测试。图 3.3说明了 XP 流程并指出了与每个框架活动相关的一些关键思想和任务。以下段落总结了关键的 XP 活动。

Extreme Programming encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding, and testing. Figure 3.3 illustrates the XP process and notes some of the key ideas and tasks that are associated with each framework activity. The key XP activities are summarized in the paragraphs that follow.

图3.3 极限编程流程

Figure 3.3 The Extreme Programming process

规划。规划活动(也称为规划游戏)从称为“倾听”的需求活动开始。倾听会导致创建一组“故事”(也称为用户故事),这些故事描述了要构建的软件所需的输出、特性和功能。每个用户故事第 7 章中描述)均由客户编写并放置在索引卡上。客户根据特性或功能的整体业务价值为故事分配一个值(即优先级)。7然后,XP 团队的成员评估每个故事并为其分配成本以开发周为单位进行衡量)。需要注意的是,新的故事可以随时编写。

Planning. The planning activity (also called the planning game) begins with a requirements activity called listening. Listening leads to the creation of a set of “stories” (also called user stories) that describe required output, features, and functionality for software to be built. Each user story (described in Chapter 7) is written by the customer and is placed on an index card. The customer assigns a value (i.e., a priority) to the story based on the overall business value of the feature or function.7 Members of the XP team then assess each story and assign a cost—measured in development weeks—to it. It is important to note that new stories can be written at any time.

客户和开发人员共同决定如何将故事分组到由 XP 团队开发的下一个版本(下一个软件增量)中。一旦对发布做出了基本承诺(就要包含的故事、交付日期和其他项目事项达成一致),XP 团队就会订购将通过以下三种方式之一开发的故事:(1) 所有故事都将得到实施立即(几周内),(2)价值最高的故事将在时间表中上移并首先实施,或(3)风险最高的故事将在时间表中上移并首先实施。第 47 页

Customers and developers work together to decide how to group stories into the next release (the next software increment) to be developed by the XP team. Once a basic commitment (agreement on stories to be included, delivery date, and other project matters) is made for a release, the XP team orders the stories that will be developed in one of three ways: (1) all stories will be implemented immediately (within a few weeks), (2) the stories with highest value will be moved up in the schedule and implemented first, or (3) the riskiest stories will be moved up in the schedule and implemented first.Page 47

在交付第一个项目版本(也称为软件增量)后,XP 团队计算项目速度。简而言之,项目速度是在第一个版本期间实施的客户故事的数量。然后,项目速度可用于帮助估计后续版本的交付日期和时间表。XP 团队相应地修改了其计划。

After the first project release (also called a software increment) has been delivered, the XP team computes project velocity. Stated simply, project velocity is the number of customer stories implemented during the first release. Project velocity can then be used to help estimate delivery dates and schedule for subsequent releases. The XP team modifies its plans accordingly.

设计。XP 设计严格遵循 KIS(保持简单)原则。不鼓励设计额外的功能(因为开发人员假设稍后会需要它)。8

Design. XP design rigorously follows the KIS (keep it simple) principle. The design of extra functionality (because the developer assumes it will be required later) is discouraged.8

XP 鼓励使用 CRC 卡(第 8 章)作为在面向对象环境中思考软件的有效机制。CRC(类-责任-协作者)卡识别并组织与当前软件增量相关的面向对象类9 。CRC 卡是作为 XP 流程一部分而生产的唯一设计工作产品。第48页

XP encourages the use of CRC cards (Chapter 8) as an effective mechanism for thinking about the software in an object-oriented context. CRC (class-responsibility-collaborator) cards identify and organize the object-oriented classes9 that are relevant to the current software increment. CRC cards are the only design work product produced as part of the XP process.Page 48

如果在故事设计的过程中遇到困难的设计问题,XP 建议立即创建该设计部分的操作原型。XP 的一个中心概念是设计在编码开始之前和之后进行。重构——以不改变软件外部行为的方式修改/优化代码[Fow00]——意味着设计在系统构建时不断发生。事实上,构建活动本身将为 XP 团队提供如何改进设计的指导。

If a difficult design problem is encountered as part of the design of a story, XP recommends the immediate creation of an operational prototype of that portion of the design. A central notion in XP is that design occurs both before and after coding commences. Refactoring—modifying/optimizing the code in a way that does not change the external behavior of the software [Fow00]—means that design occurs continuously as the system is constructed. In fact, the construction activity itself will provide the XP team with guidance on how to improve the design.

编码。在开发用户故事并完成初步设计工作后,团队不会转向代码,而是开发一系列单元测试,这些单元测试将演练要包含在当前版本(软件增量)中的每个故事。10一旦创建了单元测试11 ,开发人员就能够更好地关注必须实现哪些内容才能通过测试。代码完成后,可以立即进行单元测试,从而为开发人员提供即时反馈。

Coding. After user stories are developed and preliminary design work is done, the team does not move to code, but rather develops a series of unit tests that will exercise each of the stories that is to be included in the current release (software increment).10 Once the unit test11 has been created, the developer is better able to focus on what must be implemented to pass the test. Once the code is complete, it can be unit-tested immediately, thereby providing instantaneous feedback to the developers.

编码活动中的一个关键概念(也是 XP 中讨论最多的方面之一)是结对编程。XP 建议两个人在一台计算机上一起工作来为故事创建代码。这提供了一种实时问题解决(两个头通常比一个更好)和实时质量保证(代码在创建时进行审查)的机制。12

A key concept during the coding activity (and one of the most talked-about aspects of XP) is pair programming. XP recommends that two people work together at one computer to create code for a story. This provides a mechanism for real-time problem solving (two heads are often better than one) and real-time quality assurance (the code is reviewed as it is created).12

当结对程序员完成他们的工作时,他们开发的代码会与其他人的工作集成。这种“持续集成”策略有助于尽早发现兼容性和接口错误。

As pair programmers complete their work, the code they develop is integrated with the work of others. This “continuous integration” strategy helps uncover compatibility and interfacing errors early.

测试。创建的单元测试应该使用能够实现自动化的框架来实现(因此,它们可以轻松且重复地执行)。这鼓励每当代码修改时实施回归测试策略(第 20 章)(考虑到 XP 重构原理,这种情况很常见)。XP验收测试也称为客户测试,由客户指定,重点关注客户可见且可审查的整体系统特性和功能。它们源自作为软件版本的一部分实现的用户故事。

Testing. The unit tests that are created should be implemented using a framework that enables them to be automated (hence, they can be executed easily and repeatedly). This encourages implementing a regression testing strategy (Chapter 20) whenever code is modified (which is often, given the XP refactoring philosophy). XP acceptance tests, also called customer tests, are specified by the customer and focus on overall system features and functionality that are visible and reviewable by the customer. They are derived from user stories that have been implemented as part of a software release.

3.5.2 看板

3.5.2 Kanban

看板方法 [And16] 是一种精益方法,描述了改进任何流程或工作流程的方法看板专注于变革管理和服务交付。变更管理定义了将请求的变更集成到基于软件的系统中的过程。通过关注了解客户的需求和期望来鼓励提供服务。团队成员负责管理工作,并可以自由地组织起来完成工作。政策根据需要不断发展以改善结果。第 49 页

The Kanban method [And16] is a lean methodology that describes methods for improving any process or workflow. Kanban is focused on change management and service delivery. Change management defines the process through which a requested change is integrated into a software-based system. Service delivery is encouraged by focusing on understanding customer needs and expectations. The team members manage the work and are given the freedom to organize themselves to complete it. Policies evolve as needed to improve outcomes.Page 49

看板起源于丰田,作为一套工业工程实践,并由 David Anderson 改编为软件开发[And16]。看板本身取决于六个核心实践:

Kanban originated at Toyota as a set of industrial engineering practices and was adapted to software development by David Anderson [And16]. Kanban itself depends on six core practices:

  1. 使用看板可视化工作流程(示例如图3.4所示)。看板被组织成代表软件功能每个元素的开发阶段的列​​。黑板上的卡片可能包含单个用户故事或最近在便签上发现的缺陷,随着项目的进展,团队会将它们从“要做”推进到“正在做”和“已完成”。

  2. Visualizing workflow using a Kanban board (an example is shown in Figure 3.4). The Kanban board is organized into columns representing the development stage for each element of software functionality. The cards on the board might contain single user stories or recently discovered defects on sticky notes and the team would advance them from “to do,” to “doing,” and “done” as the project progresses.

  3. 限制任何给定时间的在制品(WIP)数量。我们鼓励开发人员在开始另一个任务之前完成当前的任务。这减少了交付时间,提高了工作质量,并提高了团队向利益相关者频繁交付软件功能的能力。

  4. Limiting the amount of work in progress (WIP) at any given time. Developers are encouraged to complete their current task before starting another. This reduces lead time, improves work quality, and increases the team’s ability to deliver software functionality frequently to their stakeholders.

  5. 通过了解当前的价值流、分析停滞的地方、定义变更,然后实施变更,管理工作流程以减少浪费。

  6. Managing workflow to reduce waste by understanding the current value flow, analyzing places where it is stalled, defining changes, and then implementing the changes.

  7. 明确流程政策(例如,写下选择要处理的项目的原因以及用于定义“完成”的标准)。

  8. Making process policies explicit (e.g., write down your reasons for selecting items to work on and the criteria used to define “done”).

  9. 通过创建反馈循环来专注于持续改进,其中根据流程数据引入变更,并在变更后衡量变更对流程的影响。13

  10. Focusing on continuous improvement by creating feedback loops where changes are introduced based on process data and the effects of the change on the process are measured after the changes are made.13

  11. 协作进行流程变更,并根据需要让所有团队成员和其他利益相关者参与进来。

  12. Make process changes collaboratively and involve all team members and other stakeholders as needed.

图3.4看板 _

Figure 3.4 Kanban board

第50页

Page 50

看板的团队会议与 Scrum 框架中的团队会议类似。如果将看板引入现有项目,则并非所有项目都会在待办事项列中开始。开发人员需要将他们的卡片放在团队流程栏中,问自己:他们现在在哪里?哪儿来的呢?他们要去哪?

The team meetings for Kanban are like those in the Scrum framework. If Kanban is being introduced to an existing project, not all items will start in the backlog column. Developers need to place their cards in the team process column by asking themselves: Where are they now? Where did they come from? Where are they going?

每日看板站立会议的基础是一项称为“走板”的任务。该会议的领导每天轮换。团队成员识别看板上缺少的正在处理的任何项目,并将其添加到看板中。团队试图推进他们能够“完成”的任何项目。目标是首先推进高商业价值项目。团队查看流程并尝试通过查看工作量和风险来识别完成的任何障碍。

The basis of the daily Kanban standup meeting is a task called “walking the board.” Leadership of this meeting rotates daily. The team members identify any items missing from the board that are being worked on and add them to the board. The team tries to advance any items they can to “done.” The goal is to advance the high business value items first. The team looks at the flow and tries to identify any impediments to completion by looking at workload and risks.

在每周回顾会议期间,将对过程测量进行检查。该团队考虑哪些地方可能需要改进流程,并提出要实施的更改。看板可以轻松地与其他敏捷开发实践相结合,以添加更多的流程规则。

During the weekly retrospective meeting, process measurements are examined. The team considers where process improvements may be needed and proposes changes to be implemented. Kanban can easily be combined with other agile development practices to add a little more process discipline.

3.5.3 开发运营

3.5.3 DevOps

DevOps 由 Patrick DeBois [Kim16a] 创建,旨在将开发和运营结合起来。DevOps 尝试在整个软件供应链中应用敏捷和精益开发原则。图 3.5概述了 DevOps 工作流程。DevOps 方法涉及几个连续循环的阶段,直到出现所需的产品:

DevOps was created by Patrick DeBois [Kim16a] to combine Development and Operations. DevOps attempts to apply agile and lean development principles across the entire software supply chain. Figure 3.5 presents an overview of the DevOps workflow. The DevOps approach involves several stages that loop continuously until the desired product exists:

图3.5 DevOps _

Figure 3.5 DevOps

  • 不断发展。软件可交付成果在多个冲刺中进行分解和开发,并将增量交付给质量保证团队的14 名成员进行测试

  • Continuous development. Software deliverables are broken down and developed in multiple sprints with the increments delivered to the quality assurance14 members of the development team for testing

  • 持续测试。自动化测试工具15用于帮助团队成员同时测试多个代码增量,以确保它们在集成之前没有缺陷。

  • Continuous testing. Automated testing tools15 are used to help team members test multiple code increments at the same time to ensure they are free of defects prior to integration.

  • 持续集成。将具有新功能的代码片段添加到现有代码和运行时环境中,然后检查以确保部署后没有错误。

  • Continuous integration. The code pieces with new functionality are added to the existing code and to the run-time environment and then checked to ensure there are no errors after deployment.

  • 持续部署。在此阶段,集成代码将部署(安装)到生产环境,其中可能包括全球多个需要准备接收新功能的站点。

  • Continuous deployment. At this stage the integrated code is deployed (installed) to the production environment, which might include multiple sites globally that need to be prepared to receive the new functionality.

  • 持续监控。作为开发团队成员的运营人员通过监控生产环境中的性能并在用户发现可能的问题之前主动查找可能的问题来帮助提高软件质量。

  • Continuous monitoring. Operations staff who are members of the development team help to improve software quality by monitoring its performance in the production environment and proactively looking for possible problems before users find them.

DevOps 通过快速响应客户的需求或愿望的变化来增强客户的体验。这可以提高品牌忠诚度并增加市场份额。DevOps 等精益方法可以通过减少返工并允许转向更高业务价值的活动,为组织提供更高的创新能力。在消费者能够使用产品之前,产品不会赚钱,而 DevOps 可以为生产平台提供更快的部署时间 [Sha17]。

DevOps enhances customers’ experiences by reacting quickly to changes in their needs or desires. This can increase brand loyalty and increase market share. Lean approaches like DevOps can provide organizations with increased capacity to innovate by reducing rework and allowing shifts to higher business value activities. Products do not make money until consumers have access to them, and DevOps can provide faster deployment time to production platforms [Sha17].

第51页

Page 51

3.6 总结

3.6 Summary

在现代经济中,市场状况瞬息万变,客户和最终用户的需求不断变化,新的竞争威胁毫无预警地出现。从业者必须以一种能够保持敏捷性的方式来处理软件工程——定义可操作的、自适应的、精益的流程,以满足现代业务的需求。

In a modern economy, market conditions change rapidly, customer and end-user needs evolve, and new competitive threats emerge without warning. Practitioners must approach software engineering in a manner that allows them to remain agile—to define maneuverable, adaptive, lean processes that can accommodate the needs of modern business.

软件工程的敏捷哲学强调四个关键问题:能够控制其所执行工作的自组织团队的重要性、团队成员之间以及从业者与客户之间的沟通与协作、认识到变革代表着机会,以及强调快速交付令客户满意的软件。敏捷过程模型的设计就是为了解决这些问题。

An agile philosophy for software engineering stresses four key issues: the importance of self-organizing teams that have control over the work they perform, communication and collaboration between team members and between practitioners and their customers, a recognition that change represents an opportunity, and an emphasis on rapid delivery of software that satisfies the customer. Agile process models have been designed to address each of these issues.

表 3.1总结了我们讨论的敏捷方法的一些优点和缺点。在本书的前几版中,我们讨论了许多其他内容。现实情况是,没有一种敏捷方法对于每个项目都是完美的。敏捷开发人员在自我指导的团队中工作,并有权创建自己的流程模型。

Some of the strengths and weaknesses of the agile methods we discussed are summarized in Table 3.1. In previous editions of this book we have discussed many others. The reality is that no agile method is perfect for every project. Agile developers work on self-directed teams and are empowered to create their own process models.

Scrum 强调使用一组软件过程模式,这些模式已被证明对于时间紧迫、需求不断变化和业务关键性的项目是有效的。Scrum 团队没有理由不采用看板图来帮助组织其日常计划会议。第52页

Scrum emphasizes the use of a set of software process patterns that have proven effective for projects with tight time lines, changing requirements, and business criticality. There is no reason why a Scrum team could not adopt the use of a Kanban chart to help organize its daily planning meeting.Page 52

极限编程 (XP) 围绕四个框架活动进行组织——规划、设计、编码测试——XP 提出了许多创新且强大的技术,这些技术允许敏捷团队创建频繁的软件版本,以提供已描述和描述的特性和功能。然后由利益相关者确定优先顺序。没有什么可以阻止他们使用 DevOps 技术来缩短部署时间。

Extreme programming (XP) is organized around four framework activities—planning, design, coding, and testing—XP suggests a number of innovative and powerful techniques that allow an agile team to create frequent software releases that deliver features and functionality that have been described and then prioritized by stakeholders. There is nothing preventing them from using DevOps techniques to decrease their time to deployment.

问题与思考点

Problems and Points to Ponder

3.1. 阅读本章开头提到的“敏捷软件开发宣言”[Bec01]。您能想到四种“价值观”中的一个或多个可能会给软件团队带来麻烦的情况吗?第53页

3.1. Read the “Manifesto of Agile Software Development” [Bec01] noted at the beginning of this chapter. Can you think of a situation in which one or more of the four “values” could get a software team into trouble?Page 53

3.2. 用您自己的话描述敏捷性(对于软件项目)。

3.2. Describe agility (for software projects) in your own words.

3.3. 为什么迭代过程可以更轻松地管理变更?本章讨论的每个敏捷过程都是迭代的吗?是否有可能仅在一次迭代中完成一个项目并且仍然保持敏捷?解释你的答案。

3.3. Why does an iterative process make it easier to manage change? Is every agile process discussed in this chapter iterative? Is it possible to complete a project in just one iteration and still be agile? Explain your answers.

3.4. 尝试提出另一个“敏捷性原则”,以帮助软件工程团队变得更加机动。

3.4. Try to come up with one more “agility principle” that would help a software engineering team become even more maneuverable.

3.5. 为什么需求变化这么大?毕竟,人们不知道自己想要什么吗?

3.5. Why do requirements change so much? After all, don’t people know what they want?

3.6. 大多数敏捷流程模型都建议面对面的沟通。然而如今,软件团队的成员及其客户可能在地理上彼此分离。您认为这是否意味着需要避免地理隔离?你能想办法克服这个问题吗?

3.6. Most agile process models recommend face-to-face communication. Yet today, members of a software team and their customers may be geographically separated from one another. Do you think this implies that geographical separation is something to avoid? Can you think of ways to overcome this problem?

3.7. 编写一个用户故事,描述大多数 Web 浏览器上提供的“最喜欢的地方”或“最喜欢的”功能。

3.7. Write a user story that describes the “favorite places” or “favorites” feature available on most Web browsers.

3.8. 用您自己的话描述重构和结对编程的 XP 概念。

3.8. Describe the XP concepts of refactoring and pair programming in your own words.

1敏捷方法有时称为轻型方法精益方法。

1 Agile methods are sometimes referred to as light methods or lean methods.

2敏捷联盟主页包含许多有用的信息:https://www.agilealliance.org/。

2 The Agile Alliance home page contains much useful information: https://www.agilealliance.org/.

3一群球员围成一圈,队友们齐心协力(有时甚至很暴力!)将球传到前场。

3 A group of players forms around the ball, and the teammates work together (sometimes violently!) to move the ball downfield.

4时间是一个项目管理术语(参见本书第四部分),它表示为完成某项任务而分配的一段时间。

4 A time-box is a project management term (see Part Four of this book) that indicates a period of time that has been allocated to accomplish some task.

5 Scrum 指南可在以下网址获取:https://www.Scrum.org/resources/what-is-Scrum。

5 The Scrum Guide is available at: https://www.Scrum.org/resources/what-is-Scrum.

6这并不是一件坏事。在一种或多种模型或方法被接受为事实标准之前,所有模型或方法都必须赢得软件工程师的青睐。“赢家”演变成最佳实践,而“输家”要么消失,要么与获胜模型合并。

6 This is not a bad thing. Before one or more models or methods are accepted as a de facto standard, all must contend for the hearts and minds of software engineers. The “winners” evolve into best practice, while the “losers” either disappear or merge with the winning models.

7一个故事的价值也可能取决于另一个故事的存在。

7 The value of a story may also be dependent on the presence of another story.

8尽管有时复杂的设计符号和术语可能会妨碍简单性,但每种软件工程方法都应遵循这些设计指南。

8 These design guidelines should be followed in every software engineering method, although there are times when sophisticated design notation and terminology may get in the way of simplicity.

本书第二部分讨论了9 个面向对象的类。

9 Object-oriented classes are discussed throughout Part Two of this book.

10这种方法类似于在开始学习之前了解考试问题。通过仅将注意力集中在将提出的问题上,使学习变得更加容易。

10 This approach is analogous to knowing the exam questions before you begin to study. It makes studying much easier by focusing attention only on the questions that will be asked.

11第 20 章详细讨论的单元测试侧重于单个软件组件,测试组件的接口、数据结构和功能,以发现组件本地的错误。

11 Unit testing, discussed in detail in Chapter 20, focuses on an individual software component, exercising the component’s interface, data structures, and functionality in an effort to uncover errors that are local to the component.

12结对编程在整个软件社区中变得如此普遍,以至于《华尔街日报》 [Wal12] 刊登了有关该主题的头版报道。

12 Pair programming has become so widespread throughout the software community that The Wall Street Journal [Wal12] ran a front-page story about the subject.

13第 23 章讨论了流程度量的使用。

13 The use of process metrics is discussed in Chapter 23.

14第 17 章讨论了质量保证。

14 The quality assurance is discussed in Chapter 17.

15第 19 章讨论了自动化测试工具。

15 Automated testing tools are discussed in Chapter 19.

第 54 页

Page 54

章节

chapter

4推荐流程模型

4 Recommended Process Model

第2章和第3章中,我们简要描述了几种软件过程模型和软件工程框架。每个项目都是不同的,每个团队都是不同的。不存在适合每种软件产品的单一软件工程框架。在本章中,我们将分享我们对使用适应性流程的想法,该流程可以根据开发多种类型产品的软件开发人员的需求进行定制。

In Chapters 2 and 3, we provided brief descriptions of several software process models and software engineering frameworks. Every project is different, and every team is different. There is no single software engineering framework that is appropriate for every software product. In this chapter, we’ll share our thoughts on using an adaptable process that can be tailored to fit the needs of software developers working on many types of products.

第55页Rajagoplan [Raj14] 的一篇论文回顾了规范性软件生命周期方法(例如瀑布模型)的一般弱点,并包含在组织现代软件开发项目时应考虑的几条建议。

Page 55A paper by Rajagoplan [Raj14] reviews the general weaknesses of prescriptive software life-cycle approaches (e.g., the waterfall model) and contains several suggestions that should be considered when organizing a modern software development project.

  1. 在没有足够反馈的情况下使用线性过程模型是有风险的。

  2. It is risky to use a linear process model without ample feedback.

  3. 计划大量的预先需求收集是不可能也不可取的。

  4. It is never possible nor desirable to plan big up-front requirements gathering.

  5. 预先收集需求可能不会降低成本或防止时间延误。

  6. Up-front requirements gathering may not reduce costs or prevent time slippage.

  7. 适当的项目管理是软件开发不可或缺的一部分。

  8. Appropriate project management is integral to software development.

  9. 文档应该随着软件的发展而发展,并且不应该延迟构建的开始。

  10. Documents should evolve with the software and should not delay the start of construction.

  11. 让利益相关者尽早并频繁地参与开发过程。

  12. Involve stakeholders early and frequently in the development process.

  13. 测试人员需要参与软件构建之前的过程。

  14. Testers need to become involved in the process prior to software construction.

2.6 节中,我们列出了几种规范性流程模型的优缺点。瀑布模型不适合开发人员开始编码后可能需要引入的更改。因此,利益相关者的反馈仅限于项目开始和结束时。部分原因是瀑布模型建议在任何编程或测试发生之前完成所有分析和设计工作产品。这使得很难适应不断变化的需求的项目。

In Section 2.6, we listed the pros and cons of several prescriptive process models. The waterfall model is not amenable to changes that may need to be introduced once developers start coding. Stakeholder feedback is therefore limited to the beginning and end of the project. Part of the reason for this is the waterfall model suggests that all analysis and design work products be completed before any programming or testing occurs. This makes it hard to adapt to projects with evolving requirements.

一种诱惑是切换到增量模型(图 4.1),例如原型模型或 Scrum。增量流程模型尽早且经常让客户参与进来,因此降低了创建不被客户接受的产品的风险。当利益相关者查看每个原型并意识到他们现在意识到他们需要的功能和特性缺失时,就会有鼓励进行大量更改的诱惑。通常,开发人员不会计划原型的演变并创建一次性原型。回想一下,软件工程的目标是减少不必要的工作,因此设计原型时需要考虑到重用。如果可以明智地管理变更,增量模型确实为创建适应性流程提供了更好的基础。

One temptation is to switch to an incremental model (Figure 4.1) like the prototyping model or Scrum. Incremental process models involve customers early and often and therefore reduce the risk of creating product that is not accepted by the customers. There is a temptation to encourage lots of changes as stakeholders view each prototype and realize that functions and features they now realize they need are missing. Often, developers do not plan for prototype evolution and create throwaway prototypes. Recall that the goal of software engineering is to reduce unnecessary effort, so prototypes need to be designed with reuse in mind. Incremental models do provide a better basis for creating an adaptable process if changes can be managed wisely.

图4.1 原型开发的增量模型

Figure 4.1 Incremental model for prototype development

第56页3.5 节中,我们讨论了除 Scrum 之外的几种敏捷流程模型的优缺点。敏捷过程模型非常擅长适应有关利益相关者实际需求和问题的不确定知识。敏捷过程模型的主要特征是:

Page 56In Section 3.5, we discussed the pros and cons of several agile process models other than Scrum. Agile process models are very good at accommodating the uncertain knowledge about the stakeholders’ real needs and problems. Key characteristics of agile process models are:

  • 创建的原型旨在在未来的软件增量中进行扩展。

  • Prototypes created are designed to be extended in future software increments.

  • 利益相关者参与整个开发过程。

  • Stakeholders are involved throughout the development process.

  • 文档要求很轻,文档应该随着软件的发展而发展。

  • Documentation requirements are lightweight, and documentation should evolve along with the software.

  • 测试是尽早计划和执行的。

  • Testing is planned and executed early.

Scrum 和看板扩展了这些特征。Scrum 有时因需要召开太多会议而受到批评。但每天的会议让开发人员很难偏离构建利益相关者认为有用的产品太远。看板(第 3.5.2 节)提供了一个良好的轻量级跟踪系统,用于管理用户故事的状态和优先级。

Scrum and Kanban extend these characteristics. Scrum is sometimes criticized for requiring too many meetings. But daily meetings make it hard for developers to stray too far from building products that stakeholders find useful. Kanban (Section 3.5.2) provides a good lightweight tracking system for managing the status and priorities of user stories.

Scrum 和看板都允许受控地引入新需求(用户故事)。敏捷团队在设计上规模较小,可能不适合需要大量开发人员的项目,除非项目可以划分为小型且可独立分配的组件。尽管如此,敏捷流程模型提供了许多可以合并到适应性流程模型中的良好功能。

Both Scrum and Kanban allow for controlled introduction of new requirements (user stories). Agile teams are small by design and may not be suitable for projects requiring large numbers of developers, unless the project can be partitioned into small and independently assignable components. Still, agile process models offer many good features that can be incorporated into an adaptable process model.

螺旋模型(图 4.2)可以被视为具有风险评估元素的演化原型模型。螺旋模型依赖于利益相关者的适度参与,是为大型团队和大型项目设计的。其目标是在每次迭代流程时创建可扩展的原型。早期测试至关重要。文档随着每个新原型的创建而演变。螺旋模型有些独特,因为它内置了正式的风险评估,并用作决定是否投资创建下一个原型所需的资源的基础。有些人认为,使用螺旋模型管理项目可能很困难,因为项目范围在项目开始时可能不知道。这是大多数增量流程模型的典型特征。螺旋是构建适应性流程模型的良好基础。

The spiral model (Figure 4.2) can be thought of as an evolutionary prototyping model with a risk assessment element. The spiral model relies on moderate stakeholder involvement and was designed for large teams and large projects. Its goal is to create extensible prototypes each time the process is iterated. Early testing is essential. Documentation evolves with the creation of each new prototype. The spiral model is somewhat unique in that formal risk assessment is built in and used as the basis for deciding whether to invest the resources needed to create the next prototype. Some people argue that it may be hard to manage a project using the spiral model, because the project scope may not be known at the start of the project. This is typical of most incremental process models. The spiral is a good basis for building an adaptable process model.

图4.2原型 开发的螺旋模型

Figure 4.2 Spiral model for prototype development

第 57 页敏捷流程模型与演化模型相比如何?我们在侧边栏中总结了一些关键特征。

Page 57How do agile process models compare to evolutionary models? We’ve summarized some of the key characteristics in a sidebar.

富有创造力、知识渊博的人从事软件工程。他们调整软件流程,使其适合他们构建的产品并满足市场的需求。我们认为,对于许多软件项目来说,使用在每个周期中都具有敏捷性的螺旋式方法是一个很好的起点。开发人员在开发过程中会学到很多东西。这就是为什么开发人员能够尽快调整他们的流程以适应这些新知识非常重要。

Creative, knowledgeable people perform software engineering. They adapt software processes to make them appropriate for the products that they build and to meet the demands of the marketplace. We think that using a spiral-like approach that has agility built into every cycle is a good place to start for many software projects. Developers learn many things as they proceed in the development process. That’s why it is important for developers to be able to adapt their process as quickly as practical to accommodate this new knowledge.

第58页

Page 58

4.1 需求定义

4.1 Requirements Definition

每个软件项目都始于团队尝试了解要解决的问题并确定哪些结果对利益相关者很重要。这包括了解推动项目的业务需求以及限制项目的技术问题。这个过程称为需求工程,将在第 7 章中更详细地讨论。未能在这项任务上花费合理时间的团队会发现他们的项目包含昂贵的返工、成本超支、产品质量差、交付时间延迟、客户不满意以及团队士气低落。需求工程不能被忽视,也不能允许它在进行产品构建之前无休止地迭代。

Every software project begins with the team trying to understand the problem to be solved and determining what outcomes are important to the stakeholders. This includes understanding the business needs motivating the project and the technical issues which constrain it. This process is called requirements engineering and will be discussed in more detail in Chapter 7. Teams that fail to spend a reasonable amount of time on this task will find that their project contains expensive rework, cost overruns, poor product quality, late delivery times, dissatisfied customers, and poor team morale. Requirements engineering cannot be neglected, nor can it be allowed to iterate endlessly before proceeding to product construction.

有理由问应该遵循哪些最佳实践来实现彻底而敏捷的需求工程。Scott Ambler [Amb12] 提出了几种敏捷需求定义的最佳实践:

It’s reasonable to ask what best practices should be followed to achieve thorough and agile requirements engineering. Scott Ambler [Amb12] suggests several best practices for agile requirements definition:

  1. 通过匹配利益相关者的可用性并重视他们的投入,鼓励利益相关者积极参与。

  2. Encourage active stakeholder participation by matching their availability and valuing their input.

  3. 使用简单的模型(例如便利贴、快速草图、用户故事)来减少参与障碍。

  4. Use simple models (e.g., Post-it notes, fast sketches, user stories) to reduce barriers to participation.

  5. 在使用需求表示技术之前,花点时间解释一下它们。

  6. Take time to explain your requirement representation techniques before using them.

  7. 采用利益相关者术语,并尽可能避免使用技术术语。

  8. Adopt stakeholder terminology, and avoid technical jargon whenever possible.

  9. 使用广度优先的方法来了解项目的整体情况,然后再陷入细节之中。

  10. Use a breadth-first approach to get the big picture of the project done before getting bogged down in details.

  11. 允许开发团队在计划实施用户故事时“及时”完善(根据利益相关者的意见)需求细节。

  12. Allow the development team to refine (with stakeholder input) requirement details “just in time” as user stories are scheduled to be implemented.

  13. 将要实现的功能列表视为优先级列表,并首先实现最重要的用户故事。

  14. Treat the list of features to be implemented like a prioritized list, and implement the most important user stories first.

  15. 与您的利益相关者密切合作,并且在创建下一个原型时仅记录对所有人有用的级别的需求。

  16. Collaborate closely with your stakeholders and only document requirements at a level that is useful to all when creating the next prototype.

  17. 质疑是否需要维护将来不会引用的模型和文档。

  18. Question the need to maintain models and documents that will not be referred to in the future.

  19. 确保您拥有管理支持,以确保需求定义期间利益相关者和资源的可用性。

  20. Make sure you have management support to ensure stakeholder and resource availability during requirements definition.

认识到两个现实很重要:(1) 利益相关者在看到工作软件之前不可能描述整个系统,(2) 利益相关者在看到软件实际运行之前很难描述软件所需的质量要求。开发人员必须认识到,随着软件增量的创建,需求将被添加和细化。在用户故事中捕获利益相关者对系统需要做什么的描述是一个很好的起点。

It is important to recognize two realities: (1) it is impossible for stakeholders to describe an entire system before seeing the working software, and (2) it is difficult for stakeholders to describe quality requirements needed for the software before seeing it in action. Developers must recognize that requirements will be added and refined as the software increments are created. Capturing stakeholders’ descriptions about what the system needs to do in their own words in a user story is a good place to begin.

如果您可以让利益相关者为每个用户故事定义接受标准,那么您的团队就有了一个良好的开端。利益相关者可能需要查看用户故事的编码和运行,以了解其是否已正确实施。因此,需求定义需要迭代完成,并包括开发原型以供利益相关者审查。

If you can get stakeholders to define acceptance criteria for each user story, your team is off to a great start. It is likely that stakeholders will need to see a user story coded and running to know whether it has been implemented correctly or not. Therefore, requirements definition needs to be done iteratively and include the development of prototypes for stakeholder review.

原型是项目计划的有形实现,利益相关者在尝试描述所需的更改时可以轻松引用。利益相关者有动力以更具体的方式讨论需求变更,从而改善沟通。重要的是要认识到原型允许开发人员通过仅关注用户的可见行为来关注短期目标。审查原型时关注质量非常重要。开发人员需要意识到,如果利益相关者不专注于第一次就把事情做好,那么使用原型可能会增加需求的波动性。还存在这样的风险:在充分理解软件架构需求之前创建原型可能会导致原型必须被丢弃,浪费时间和资源 [Kap15]。

Prototypes are tangible realizations of project plans that can be easily referenced by stakeholders when trying to describe desired changes. Stakeholders are motivated to discuss requirements changes in more concrete terms, which improves communication. It’s important to recognize that prototypes allow developers to focus on short-term goals by only focusing on users’ visible behaviors. It will be important to review prototypes with an eye to the quality. Developers need to be aware that using prototypes may increase the volatility of the requirements if stakeholders are not focused on getting things right the first time. There is also the risk that creating prototypes before the software architectural requirements are well understood may result in prototypes that must be discarded, wasting time and resources [Kap15].

第59页

Page 59

4.2 初步架构设计

4.2 Preliminary Architectural Design

第 10 章讨论了开发可靠的架构设计所需的决策,但通常必须在定义需求时做出初步设计决策。如图 4.3所示,在某个时间点,架构决策需要分配给产品增量。Bellomo 和她的同事 [Bel14] 认为,早期了解需求和架构选择是管理大型或复杂软件产品开发的关键。

The decisions required to develop a solid architectural design are discussed in Chapter 10, but preliminary design decisions must often be made as requirements are defined. As shown in Figure 4.3, at some point in time, architectural decisions will need to be allocated to product increments. According to Bellomo and her colleagues [Bel14], early understanding of requirements and architecture choices is key to managing the development of large or complex software products.

4.3 原型开发的架构设计

Figure 4.3 Architectural design for prototype development

第 60 页需求可用于指导架构设计。在开发原型时探索架构有助于详细说明需求的过程。最好同时进行这些活动以达到适当的平衡。敏捷架构设计有四个关键要素:

Page 60Requirements can be used to inform architecture design. Exploring the architecture as the prototype is developed facilitates the process of detailing the requirements. It is best to conduct these activities concurrently to achieve the right balance. There are four key elements to agile architectural design:

  1. 关注关键的质量属性,并在构建原型时将其纳入原型中。

  2. Focus on key quality attributes, and incorporate them into prototypes as they are constructed.

  3. 在规划原型时,请记住,成功的软件产品结合了客户可见的功能和支持这些功能的基础设施。

  4. When planning prototypes, keep in mind that successful software products combine customer-visible features and the infrastructure to enable them.

  5. 认识到如果对架构决策和相关的质量问题给予足够的关注,敏捷架构可以实现代码的可维护性和可演化性。

  6. Recognize that an agile architecture enables code maintainability and evolvability if sufficient attention is paid to architectural decisions and related quality issues.

  7. 需要持续管理和同步功能和架构需求之间的依赖关系,以确保不断发展的架构基础能够及时为未来的增量做好准备。

  8. Continuously managing and synchronizing dependencies between the functional and architectural requirements is needed to ensure the evolving architectural foundation will be ready just in time for future increments.

软件架构决策对于软件系统的成功至关重要。软件系统的架构决定了其质量并影响系统的整个生命周期。达萨纳亚克等人。[Das15] 发现,软件架构师在不确定的情况下做出决策时很容易犯错误。如果架构师能够通过更好的架构知识管理来减少这种不确定性,那么他们就会做出更少的错误决策。尽管敏捷方法不鼓励大量记录,但未能在设计过程的早期记录设计决策及其基本原理,使得在创建未来原型时很难重新审视它们。记录正确的事情可以帮助流程改进活动。记录您所学到的经验教训是在评估交付的原型之后和开始下一个项目增量之前进行回顾的原因之一。重用以前成功的架构问题解决方案也很有帮助,将在第 14 章中讨论。

Software architecture decision making is critical to the success of a software system. The architecture of a software system determines its qualities and impacts the system throughout its life cycle. Dasanayake et al. [Das15] found that software architects are prone to making errors when their decisions are made under levels of uncertainty. Architects make fewer bad decisions if they can reduce this uncertainty through better architectural knowledge management. Despite the fact that agile approaches discourage heavy documentation, failing to record design decisions and their rationale early in the design process makes it hard to revisit them when creating future prototypes. Documenting the right things can assist with process improvement activities. Documenting your lessons learned is one of the reasons that retrospectives should be conducted after evaluating the delivered prototype and before beginning the next program increment. Reuse of previously successful solutions to architectural problems is also helpful and will be discussed in Chapter 14.

4.3 资源估算

4.3 Resource Estimation

使用螺旋或敏捷原型设计更具争议性的方面之一是在无法完全定义项目时估计完成项目所需的时间。在开始之前,重要的是要了解在同意承担该项目之前,您是否有合理的机会以可接受的成本按时交付软件产品。早期的估计存在不正确的风险,因为项目范围没有明确定义,并且一旦开发开始可能会发生变化。项目即将完成时所做的估算不提供任何项目管理指导。诀窍是根据当时已知的情况尽早估计软件开发时间,并在添加需求或交付软件增量后定期修改您的估计。我们将在第 25 章中讨论估算项目范围的方法。

One of the more controversial aspects of using spiral or agile prototyping is estimating the time it will take to complete a project when it cannot be defined completely. It is important to understand before you begin whether you have a reasonable chance of delivering software products on time and with acceptable costs before you agree to take on the project. Early estimates run the risk of being incorrect because the project scope is not well defined and is likely to change once development starts. Estimates made when the project is almost finished do not provide any project management guidance. The trick is to estimate the software development time early based on what is known at the time and revise your estimates on a regular basis as requirements are added or after software increments are delivered. We discuss methods of estimating project scope in Chapter 25.

让我们看看经验丰富的软件项目经理如何使用我们提出的敏捷螺旋模型来评估项目。这种方法产生的估计需要根据开发人员的数量和可以同时完成的用户故事的数量进行调整。第61页

Let’s examine how an experienced software project manager might estimate a project using the agile spiral model we have proposed. The estimates produced by this method would need to be adjusted for the number of developers and the number of user stories that can be completed simultaneously.Page 61

  1. 使用历史数据(第 23 章),并以团队形式估算完成项目开始时已知的每个用户故事需要多少天。

  2. Use historic data (Chapter 23), and work as a team to develop an estimate of how many days it will take to complete each of the user stories known at the start of the project.

  3. 将用户故事松散地组织成组,这些组将构成计划完成原型的每个冲刺1第 3.4 节)。

  4. Loosely organize the user stories into the sets that will make up each sprint1 (Section 3.4) planned to complete a prototype.

  5. 将完成每个冲刺的天数相加,以估算整个项目的持续时间。

  6. Sum the number of days to complete each sprint to provide an estimate for the duration of the total project.

  7. 当需求添加到项目中或原型交付并被利益相关者接受时,修改估算。

  8. Revise the estimate as requirements are added to the project or prototypes are delivered and accepted by the stakeholders.

请记住,开发人员数量增加一倍几乎不会将开发时间缩短一半。

Keep in mind that doubling the number of developers almost never cuts the development time in half.

Rosa 和 Wallshein [Ros17] 发现,在项目开始时了解初始软件需求可以提供对项目完成时间的充分但并不总是准确的估计。为了获得更准确的估计,了解项目类型和团队的经验也很重要。我们将在本书的第四部分中描述更详细的估计技术(例如,功能点或用例点)。

Rosa and Wallshein [Ros17] found that knowing initial software requirements at the start of a project provides an adequate but not always accurate estimate of project completion times. To get more accurate estimates, it is also important to know the type of project and the experience of the team. We will describe more detailed estimation techniques (e.g., function points or use case points) in Part Four of this book.

4.4 第一个原型构建

4.4 First Prototype Construction

第 2.5.2 节中,我们将原型的创建描述为帮助利益相关者从一般目标和用户故事的陈述转向开发人员实现此功能所需的详细程度的一种手段。开发人员可以使用第一个原型来证明他们的初始架构设计是一种可行的方法,可以在满足客户性能约束的同时提供所需的功能。创建可操作原型意味着需求工程、软件设计和构建都是并行进行的。这个过程如图4.1所示。本节描述将用于创建第一个原型的步骤。软件设计和构建的最佳实践的详细信息将在本书后面出现。

In Section 2.5.2 we described the creation of prototypes as a means of helping the stakeholders move from statements of general objectives and user stories to the level of detail that developers will need to implement this functionality. Developers may use the first prototype to prove that their initial architectural design is a feasible approach to delivering the required functionality while satisfying the customer’s performance constraints. To create an operational prototype suggests that requirements engineering, software design, and construction all proceed in parallel. This process is shown in Figure 4.1. This section describes steps that will be used to create the first prototypes. Details of best practices for software design and construction appear later in this book.

您的首要任务是确定对利益相关者最重要的特性和功能。这些将有助于定义第一个原型的目标。如果利益相关者和开发人员创建了用户故事的优先级列表,那么应该很容易确认哪些是最重要的。

Your first task is to identify the features and functions that are most important to the stakeholders. These will help define the objectives for the first prototype. If the stakeholders and developers have created a prioritized list of user stories, it should be easy to confirm which are the most important.

接下来,决定需要多少时间来创建第一个原型。有些团队可能会选择固定时间(例如 4 周的冲刺)来交付每个原型。在这种情况下,开发人员将查看他们的时间和资源估算,并确定哪些高优先级用户故事可以在 4 周内完成。然后,团队将与利益相关者确认所选的用户故事是包含在第一个原型中的最佳用户故事。另一种方法是让利益相关者和开发人员共同选择少量高优先级的用户故事以包含在第一个原型中,并使用他们的时间和资源估计来制定完成第一个原型的时间表。第62页

Next, decide how much time will be allowed to create the first prototype. Some teams may choose a fixed time, such as a 4-week sprint, to deliver each prototype. In this case, the developers will look at their time and resource estimate and determine which of the high-priority user stories can be finished in 4 weeks. The team would then confirm with the stakeholders that the selected user stories are the best ones to include in the first prototype. An alternative approach would be to have the stakeholders and developers jointly choose a small number of high-priority user stories to include in the first prototype and use their time and resource estimates to develop the schedule to complete the first prototype.Page 62

National Instruments 的工程师发布了一份白皮书,概述了他们创建第一个功能原型的过程 [Nat15]。这些步骤可以应用于各种软件项目:

The engineers working at National Instruments published a white paper that outlines their process for creation of a first functional prototype [Nat15]. These steps can be applied to a variety of software projects:

  1. 从纸质原型到软件设计的转变

  2. Transition from paper prototype to software design

  3. 设计用户界面原型

  4. Prototype a user interface

  5. 创建虚拟原型

  6. Create a virtual prototype

  7. 向原型添加输入和输出

  8. Add input and output to your prototype

  9. 设计你的算法

  10. Engineer your algorithms

  11. 测试你的原型

  12. Test your prototype

  13. 考虑到部署的原型

  14. Prototype with deployment in mind

参考这七个步骤,为系统创建纸质原型非常便宜,并且可以在开发过程的早期完成。客户和利益相关者通常不是经验丰富的开发人员。非技术用户在看到用户界面的草图后,通常可以很快识别出他们喜欢或不喜欢用户界面的哪些方面。人与人之间的交流常常充满误解。人们忘记告诉彼此他们真正需要知道什么,或者假设每个人都有相同的理解。创建纸质原型并在进行任何编程之前与客户一起审查可以帮助避免浪费时间构建错误的原型。我们将在第 8 章中讨论可用于对系统进行建模的几个图表。

Referring to these seven steps, creating a paper prototype for a system is very inexpensive and can be done early in the development process. Customers and stakeholders are not usually experienced developers. Nontechnical users can often recognize what they like or do not like about a user interface very quickly once they see it sketched out. Communications between people are often filled with misunderstandings. People forget to tell each other what they really need to know or assume that everyone has the same understanding. Creating a paper prototype and reviewing it with the customer before doing any programming can help avoid wasted time building the wrong prototype. We will talk about several diagrams that can be used to model a system in Chapter 8.

创建原型用户界面作为第一个功能原型的一部分是一个明智的想法。许多系统是在网络上或作为移动应用程序实现的,并且严重依赖触摸用户界面。计算机游戏和虚拟现实应用程序需要与最终用户进行大量沟通才能正确运行。如果客户发现软件产品易于学习和使用,他们就更有可能使用它。

Creating a prototype user interface as part of the first functional prototype is a wise idea. Many systems are implemented on the Web or as mobile applications and rely heavily on touch user interfaces. Computer games and virtual reality applications require a great deal of communication with end users to operate correctly. If customers find a software product easy to learn and use, they are more likely to use it.

从用户界面的纸质原型开始可以减轻开发人员和利益相关者之间的许多误解。有时,利益相关者需要查看正在运行的用户界面的基础知识,以便能够解释他们真正喜欢和不喜欢的内容。放弃早期的用户界面设计比完成原型并尝试在其之上放置新的用户界面要便宜。第 12 章讨论了设计提供良好用户体验的用户界面。

Many misunderstandings between developers and stakeholders can be alleviated by beginning with a paper prototype of the user interface. Sometimes stakeholders need to see the basics of the user interface in action to be able to explain what they really like and dislike about it. It is less expensive to throw away an early user interface design than to finish the prototype and try to put a new user interface on top of it. Designing user interfaces that provide good user experiences is discussed in Chapter 12.

向用户界面原型添加输入和输出提供了一种开始测试不断发展的原型的简单方法。测试软件组件接口应该在测试构成组件算法的代码之前完成。为了测试算法本身,开发人员经常使用“测试框架”来确保他们实现的算法按预期工作。创建一个单独的测试框架并将其丢弃通常是对项目资源的不良利用。如果设计得当,用户界面可以用作组件算法的测试框架,从而消除构建单独的测试框架所需的工作。

Adding input and output to your user interface prototype provides an easy way to begin testing the evolving prototype. Testing software component interfaces should be accomplished before testing the code that makes up the component’s algorithms. To test the algorithms themselves, developers often use a “test frame” to ensure their implemented algorithms are working as intended. Creating a separate test frame and throwing it away is often a poor use of project resources. If properly designed, the user interface can serve as the test frame for component algorithms, thereby eliminating the effort required to build separate test frames.

设计你的算法是指将你的想法和草图转化为编程语言代码的过程。在设计必要的算法时,您需要考虑用户故事中规定的功能要求和性能约束(显式和隐式)。此时可能会识别其他支持功能并将其添加到项目范围(如果代码库中尚不存在)。第63页

Engineering your algorithms refers to the process of transforming your ideas and sketches into programming language code. You need to consider both the functional requirements stated in the user story and the performance constraints (both explicit and implicit) when designing the necessary algorithms. This is the point where additional support functionality is likely to be identified and added to the project scope, if it does not already exist in a code library.Page 63

在向客户演示之前,测试您的原型以展示所需的功能并识别尚未发现的缺陷。有时,在原型完成之前让客户参与测试过程是明智的,以避免开发出错误的功能。创建测试用例的最佳时间是在需求收集期间或选择用例进行实施时。第 19 章第 21 章讨论了测试策略和策略。

Testing your prototype demonstrates required functionality and identifies yet undiscovered defects before demonstrating it to the customer. Sometimes it is wise to involve the customer in the testing process before the prototype is finished to avoid developing the wrong functionality. The best time to create test cases is during requirements gathering or when use cases have been selected for implementation. Testing strategies and tactics are discussed in Chapters 19 through 21.

考虑到部署的原型设计非常重要,因为它可以帮助您避免走捷径,从而导致创建将来难以维护的软件。这并不是说每一行代码都会成为最终的软件产品。与许多创造性任务一样,开发原型是迭代的。预计会有草案和修订。

Prototyping with deployment in mind is very important because it helps you to avoid taking shortcuts that lead to creating software that will be hard to maintain in the future. This is not saying that every line of code will make it to the final software product. Like many creative tasks, developing a prototype is iterative. Drafts and revisions are to be expected.

当原型开发发生时,您应该仔细考虑您所做的软件架构选择。如果您在部署之前发现错误,则更改几行代码相对便宜。软件应用程序发布给全球最终用户后,更改其架构的成本非常昂贵。

As prototype development occurs, you should carefully consider the software architectural choices you make. It is relatively inexpensive to change a few lines of code if you catch errors before deployment. It is very expensive to change the architecture of a software application once it has been released to end users around the globe.

第64页

Page 64

4.5 原型评估

4.5 Prototype Evaluation

测试是由开发人员在原型构建时进行的,并成为原型评估的重要组成部分。测试表明原型组件可以运行,但测试用例不太可能发现所有缺陷。在螺旋模型中,评估结果允许利益相关者和开发人员评估是否需要继续开发并创建下一个原型。该决策的一部分基于用户和利益相关者的满意度,另一部分来自对成本超支和项目完成时无法交付工作产品的风险的评估。Dam 和 Siang [Dam17] 提出了一些收集原型反馈的最佳实践技巧。

Testing is conducted by the developers as the prototype is being built and becomes an important part of prototype evaluation. Testing demonstrates that prototype components are operational, but it’s unlikely that test cases will have found all the defects. In the spiral model, the results of evaluation allow the stakeholders and developers to assess whether it is desirable to continue development and create the next prototype. Part of this decision is based on user and stakeholder satisfaction, and part is derived from an assessment of the risks of cost overruns and failure to deliver a working product when the project is finished. Dam and Siang [Dam17] suggest several best-practice tips for gathering feedback on your prototype.

  1. 在寻求原型反馈时提供脚手架。

  2. Provide scaffolding when asking for prototype feedback.

  3. 在合适的人身上测试你的原型。

  4. Test your prototype on the right people.

  5. 提出正确的问题。

  6. Ask the right questions.

  7. 向用户提供替代方案时要保持中立。

  8. Be neutral when presenting alternatives to users.

  9. 在测试时进行调整。

  10. Adapt while testing.

  11. 允许用户贡献想法。

  12. Allow the user to contribute ideas.

提供脚手架是一种允许用户提供非对抗性反馈的机制。用户通常不愿意告诉开发人员他们讨厌他们正在使用的产品。为了避免这种情况,通常更容易使用“我喜欢、我希望、如果”等框架来要求用户提供反馈,作为提供开放和诚实反馈的手段。我喜欢鼓励用户对原型提供积极反馈的声明。我希望声明能够促使用户分享有关如何改进原型的想法。这些陈述可以提供负面反馈和建设性批评。What if语句鼓励用户提出想法,供您的团队在未来迭代中创建原型时探索。

Providing scaffolding is a mechanism for allowing the user to offer feedback that is not confrontational. Users are often reluctant to tell developers that they hate the product they are using. To avoid this, it is often easier to ask the user to provide feedback using a framework such as “I like, I wish, What if” as a means of providing open and honest feedback. I like statements encourage users to provide positive feedback on the prototype. I wish statements prompt users to share ideas about how the prototype can be improved. These statements can provide negative feedback and constructive criticism. What if statements encourage users to suggest ideas for your team to explore when creating prototypes in future iterations.

让合适的人来评估原型对于降低开发错误产品的风险至关重要。让开发团队成员完成所有测试并不明智,因为他们不太可能代表目标用户群体。拥有正确的用户组合(例如,新手、典型和高级)来为您提供有关原型的反馈非常重要。

Getting the right people to evaluate the prototype is essential to reduce the risk of developing the wrong product. Having development team members do all the testing is not wise because they are not likely to be the representative of the intended user population. It’s important to have the right mix of users (e.g., novice, typical, and advanced) to give you feedback on the prototype.

提出正确的问题意味着所有利益相关者都同意原型目标。作为开发人员,保持开放的心态并尽最大努力让用户相信他们的反馈很有价值,这一点很重要。当您规划未来的产品开发活动时,反馈会推动原型制作过程。除了一般反馈之外,尝试询问有关原型中包含的任何新功能的具体问题。

Asking the right questions implies that all stakeholders agree on prototype objectives. As a developer, it’s important to keep an open mind and do your best to convince users that their feedback is valuable. Feedback drives the prototyping process as you plan for future product development activities. In addition to general feedback, try to ask specific questions about any new features included in the prototype.

在提出替代方案时保持中立,可以让软件团队避免让用户感觉他们被“卖”在一种做事方式上。如果您想要诚实的反馈,请让用户知道您还没有决定只有一种正确的做事方式。无私编程是一种开发理念,专注于生产团队可以为目标用户创建的最佳产品。尽管创建一次性原型是不可取的,但无私编程表明,无法正常工作的东西需要修复或丢弃。因此,在创建早期原型时,尽量不要过于执着于自己的想法。

Be neutral when presenting alternatives allows the software team to avoid making users feel they are being “sold” on one way to do things. If you want honest feedback, let the users know that you have not already made up your mind that there is only one right way to do things. Egoless programming is a development philosophy that focuses on producing the best product the team can create for the intended users. Although it is not desirable to create throwaway prototypes, egoless programming suggests that things that are not working need to be fixed or discarded. So try not to become too attached to your ideas when creating early prototypes.

第65页测试时适应意味着在用户使用原型时您需要灵活的思维方式。这可能意味着更改您的测试计划或对原型进行快速更改,然后重新启动测试。目标是从用户那里获得最好的反馈,包括在他们与原型交互时直接观察他们。重要的是,您可以获得所需的反馈,以帮助决定是否构建下一个原型。

Page 65Adapt while testing means that you need a flexible mind-set while users are working with the prototype. This might mean altering your test plan or making quick changes to the prototype and then restarting the testing. The goal is to get the best feedback you can from users, including direct observation of them as they interact with the prototype. The important thing is that you get the feedback you need to help decide whether to build the next prototype or not.

允许用户贡献想法,言出必行。确保您有办法记录他们的建议和问题(电子或其他方式)。我们将在第 12 章中讨论进行用户测试的其他方法。

Allow users to contribute ideas means what it says. Make sure you have a way of recording their suggestions and questions (electronically or otherwise). We will discuss additional ways of conducting user testing in Chapter 12.

第66页

Page 66

4.6 继续、不继续决策

4.6 Go, No-Go Decision

评估原型后,项目利益相关者决定是否继续开发软件产品。如果您参考图 4.4,基于原型评估的一个略有不同的决定可能是向最终用户发布原型并开始维护过程。第 4.8 节第 4.9 节更详细地讨论了这一决定。我们在第 2.5.3 节中讨论了螺旋模型中风险评估的使用,作为原型评估过程的一部分。螺旋周围的第一个电路可能用于巩固项目需求。但确实应该更多。在我们在这里提出的方法中,每次螺旋之旅都会为最终软件产品带来有意义的增量。您可以使用项目用户故事或功能积压工作来确定要包含在第一个原型中的最终产品的重要子集,并为每个后续原型重复此操作。

After the prototype is evaluated, project stakeholders decide whether to continue development of the software product. If you refer to Figure 4.4, a slightly different decision based on the prototype evaluation might be to release the prototype to the end users and begin the maintenance process. Sections 4.8 and 4.9 discuss this decision in more detail. We discussed the use of risk assessment in the spiral model as part of the prototype assessment process in Section 2.5.3. The first circuit around the spiral might be used to solidify project requirements. But it really should be more. In the method we are proposing here, each trip around the spiral develops a meaningful increment of the final software product. You can work with the project user story or feature backlog to identify an important subset of the final product to include in the first prototype and repeat this for each subsequent prototype.

4.4推荐的 软件流程模型

Figure 4.4 Recommended software process model

评估过程之后会经过规划区域。根据评估当前软件原型时发现的情况,提出了修订的成本估算和时间表变更。这可能涉及在评估原型时向项目待办事项中添加新的用户故事或功能。通过将新的成本和时间估算与旧的成本和时间估算进行比较来评估超出预算和错过项目交付日期的风险。在决定创建另一个原型之前,还会与利益相关者(有时甚至是高级管理层)考虑和讨论无法满足用户期望的风险。

A pass through the planning region follows the evaluation process. Revised cost estimates and schedule changes are proposed based on what was discovered when evaluating the current software prototype. This may involve adding new user stories or features to the project backlog as the prototype is evaluated. The risk of exceeding the budget and missing the project delivery date is assessed by comparing new cost and time estimates against old ones. The risk of failing to satisfy user expectations is also considered and discussed with the stakeholders and sometimes senior management before deciding to create another prototype.

风险评估过程的目标是让所有利益相关者和公司管理层承诺提供创建下一个原型所需的资源。如果由于项目失败的风险太大而无法做出承诺,则可以终止该项目。在 Scrum 框架(第 3.4 节)中,可以在原型演示和新的冲刺计划会议之间举行的 Scrum 回顾会议期间做出进行或不进行的决定。在所有情况下,开发团队都会向产品所有者展示案例,并让他们决定是否继续产品开发。第 26 章对软件风险评估方法进行了更详细的讨论。

The goal of the risk assessment process is to get the commitment of all stakeholders and company management to provide the resources needed to create the next prototype. If the commitment is not there because the risk of project failure is too great, then the project can be terminated. In the Scrum framework (Section 3.4), the go, no-go decision might be made during the Scrum retrospective meeting held between the prototype demonstration and the new sprint planning meeting. In all cases, the development team lays out the case for the product owners and lets them decide whether to continue product development or not. A more detailed discussion of software risk assessment methods is presented in Chapter 26.

第67页

Page 67

4.7 原型演化

4.7 Prototype Evolution

一旦原型开发完成并由开发团队和其他利益相关者审查,就可以考虑开发下一个原型了。第一步是收集当前原型评估的所有反馈和数据。然后,开发人员和利益相关者开始谈判,计划创建另一个原型。一旦就新原型的所需功能达成一致,就会考虑任何已知的时间和预算限制以及实施原型的技术可行性。如果开发风险被认为是可以接受的,那么工作就会继续。

Once a prototype has been developed and reviewed by the development team and other stakeholders, it’s time to consider the development of the next prototype. The first step is to collect all feedback and data from the evaluation of the current prototype. The developers and stakeholders then begin negotiations to plan the creation of another prototype. Once the desired features for the new prototype have been agreed upon, consideration is given to any known time and budget constraints as well as the technical feasibility of implementing the prototype. If the development risks are deemed to be acceptable, the work continues.

演化原型过程模型用于适应软件开发过程中不可避免地发生的变化。每个原型的设计都应该考虑到未来的变化,以避免丢弃它并从头开始创建下一个原型。这表明在为每个原型设定目标时,应优先考虑易于理解和重要的功能。一如既往,在此过程中应高度重视客户的需求。

The evolutionary prototyping process model is used to accommodate changes that inevitably occur as software is developed. Each prototype should be designed to allow for future changes to avoid throwing it away and creating the next prototype from scratch. This suggests favoring both well-understood and important features when setting the goals for each prototype. As always, the customer’s needs should be given great importance in this process.

4.7.1 新原型范围

4.7.1 New Prototype Scope

确定新原型范围的过程类似于确定初始原型范围的过程。开发人员可以:(1)在分配给冲刺的时间内选择要开发的功能,或者(2)分配足够的时间来实现满足开发人员根据利益相关者的意见设定的目标所需的功能。这两种方法都要求开发人员维护功能或用户故事的优先级列表。用于对列表进行排序的优先级应根据利益相关者和开发人员为原型设定的目标来确定。

The process of determining the scope of a new prototype is like the process of determining the scope of the initial prototype. Developers would either: (1) select features to develop within the time allocated to a sprint, or (2) allocate sufficient time to implement the features needed to satisfy the goals set by the developers with stakeholder input. Either approach requires the developers to maintain a prioritized list of features or user stories. The priorities used to order the list should be determined by the goals set for the prototype by the stakeholders and developers.

在 XP(第 3.5.1 节)中,利益相关者和开发人员共同努力将最重要的用户故事分组到一个原型中,该原型将成为软件的下一个版本并确定其完成日期。在看板(第 3.5.2 节)中,开发人员和利益相关者利用看板来关注每个用户故事的完成状态。这是一个可视化参考,可用于帮助开发人员使用任何增量原型过程模型来规划和监控软件开发的进度。利益相关者可以轻松查看功能待办事项列表,并帮助开发人员对其进行排序,以确定下一个原型中所需的最有用的故事。估计完成所选用户故事所需的时间可能比查找需要适应固定时间段的用户故事更容易。但应遵循将原型开发时间控制在 4 至 6 周的建议,以确保利益相关者充分参与和反馈。

In XP (Section 3.5.1), the stakeholders and developers work together to group the most important user stories into a prototype that will become the next release of the software and determine its completion date. In Kanban (Section 3.5.2), developers and stakeholders make use of a board that allows them to focus on the completion status of each user story. This is a visual reference that can be used to assist developers using any incremental prototype process model to plan and monitor the progress of the software development. Stakeholders can easily see the feature backlog and help the developers order it to identify the most useful stories needed in the next prototype. It is probably easier to estimate the time required to complete the selected user stories than to find the user stories that need to fit into a fixed time block. But the advice to keep prototype development time to 4 to 6 weeks should be followed to ensure adequate stakeholder involvement and feedback.

第68页

Page 68

4.7.2 构建新原型

4.7.2 Constructing New Prototypes

用户故事应包含对客户计划如何与系统交互以实现特定目标的描述,以及对客户接受定义的描述。开发团队的任务是创建额外的软件组件来实现选择包含在新原型中的用户故事以及必要的测试用例。开发人员在创建新原型时需要继续与所有利益相关者沟通。

A user story should contain both a description of how the customer plans to interact with the system to achieve a specific goal and a description of what the customer’s definition of acceptance is. The development team’s task is to create additional software components to implement the user stories selected for inclusion in the new prototype along with the necessary test cases. Developers need to continue communication with all stakeholders as they create the new prototype.

使这个新原型构建起来更加困难的原因是,为实现不断发展的原型中的新功能而创建的软件组件需要与用于实现先前原型中包含的功能的组件配合使用。如果开发人员因需求发生变化而需要删除组件或修改先前原型中包含的组件,事情就会变得更加棘手。第 22 章讨论了管理这些类型的软件变更的策略。

What makes this new prototype trickier to build is that software components created to implement new features in the evolving prototype need to work with the components used to implement the features included in the previous prototype. It gets even trickier if developers need to remove components or modify those that were included in the previous prototype because requirements have changed. Strategies for managing these types of software changes are discussed in Chapter 22.

对于开发人员来说,做出使软件原型在未来更容易扩展的设计决策非常重要。开发人员需要以一种在制作下一个原型时更容易理解软件的方式记录设计决策。目标是在开发和文档方面保持敏捷。开发人员需要抵制过度设计软件的诱惑,以适应最终产品中可能包含或不包含的功能。他们还应该将文档限制为开发过程中或将来需要进行更改时需要参考的文档。

It is important for the developers to make design decisions that will make the software prototype more easily extensible in the future. Developers need to document design decisions in a way that will make it easier to understand the software when making the next prototype. The goal is to be agile in both development and documentation. Developers need to resist the temptation to overdesign the software to accommodate features that may or may not be included in the final product. They also should limit their documentation to that which they need to refer to during development or when changes need to be made in the future.

4.7.3 测试新原型

4.7.3 Testing New Prototypes

如果开发团队在编程完成之前创建测试用例作为设计过程的一部分,那么测试新原型应该相对简单。每个用户故事在创建时都应该附加验收标准。这些验收声明应指导测试用例的创建,以帮助验证原型是否满足客户需求。原型还需要测试缺陷和性能问题。

Testing the new prototype should be relatively straightforward if the development team created test cases as part of the design process before the programming was completed. Each user story should have had acceptance criteria attached to it as it was created. These acceptance statements should guide the creation of the test cases intended to help verify that the prototype meets customer needs. The prototype will need to be tested for defects and performance issues as well.

进化原型的另一个测试问题是确保添加新功能不会意外破坏先前原型中正常工作的功能。回归测试是验证先前开发和测试的软件在更改后是否仍然以相同方式运行的过程。明智地利用测试时间并利用旨在检测最有可能受新功能影响的组件中的缺陷的测试用例非常重要。第 20 章更详细地讨论了回归测试。

One additional testing concern for evolutionary prototypes is to ensure that adding new features does not accidentally break features that were working correctly in the previous prototype. Regression testing is the process of verifying that software that was previously developed and tested still performs the same way after it has been changed. It is important to use your testing time wisely and make use of the test cases that are designed to detect defects in the components most likely to be affected by the new features. Regression testing is discussed in more detail in Chapter 20.

4.8 原型发布

4.8 Prototype Release

当应用演化原型设计过程时,开发人员可能很难知道产品何时完成并准备好发布给客户。软件开发人员不想向最终用户发布有缺陷的软件产品,并让他们认为该软件质量很差。除了在原型构建期间进行的功能和非功能(性能)测试之外,被视为发布候选版本的原型还必须接受用户验收测试。

When an evolutionary prototyping process is applied, it can be difficult for developers to know when a product is finished and ready for release to the customers. Software developers do not want to release a buggy software product to the end users and have them decide the software has poor quality. A prototype being considered as a release candidate must be subjected to user acceptance testing in addition to functional and nonfunctional (performance) testing that would have been conducted during prototype construction.

用户验收测试基于商定的验收标准,这些标准是在创建每个用户故事并将其添加到产品待办事项列表时记录的。这使得用户代表可以验证软件的行为是否符合预期,并收集未来改进的建议。David Nielsen [Nie10] 对在工业环境中进行原型测试提出了一些建议。第69页

User acceptance tests are based on the agreed-upon acceptance criteria that were recorded as each user story was created and added to the product backlog. This allows user representatives to verify that the software behaves as expected and collect suggestions for future improvements. David Nielsen [Nie10] has several suggestions for conducting prototype testing in industrial settings.Page 69

在测试候选版本时,应使用在增量原型的构建阶段开发的测试用例来重复功能和非功能测试。应创建额外的非功能测试,以验证原型的性能与商定的最终产品基准一致。典型的性能基准可能涉及系统响应时间、数据容量或可用性。要验证的最重要的非功能性要求之一是确保候选版本将在所有计划的运行时环境和所有目标设备上运行。该过程应侧重于仅限于创建原型之前建立的验收标准的测试。测试不能证明软件产品没有错误,只能证明测试用例运行正确。

When testing a release candidate, functional and nonfunctional tests should be repeated using the test cases that were developed during the construction phases of the incremental prototypes. Additional nonfunctional tests should be created to verify that the performance of the prototype is consistent with the agreed-upon benchmarks for the final product. Typical performance benchmarks may deal with system response time, data capacity, or usability. One of the most important nonfunctional requirements to verify is ensuring that the release candidate will run in all planned run-time environments and on all targeted devices. The process should be focused on testing limited to the acceptance criteria established before the prototype was created. Testing cannot prove a software product is bug free, only that the test cases ran correctly.

验收测试期间的用户反馈应按用户界面描绘的用户可见功能进行组织。如果实施这些更改不会延迟原型的发布,那么开发人员应该检查有问题的设备并对用户界面屏幕进行更改。如果进行更改,则需要在第二轮测试中进行验证,然后才能继续。您不应计划进行两次以上的用户验收测试迭代。

User feedback during acceptance testing should be organized by user-visible functions as portrayed via the user interface. Developers should examine the device in question and make changes to the user interface screen if implementing these changes will not delay the release of the prototype. If changes are made, they need to be verified in a second round of testing before moving on. You should not plan for more than two iterations of user acceptance testing.

即使对于使用敏捷流程模型的项目,使用问题跟踪或错误报告系统(例如 Bugzilla 2或 Jira 3)来捕获测试结果也很重要。这允许开发人员记录测试失败,并更容易地识别需要再次运行的测试用例,以验证修复是否正确纠正了发现的问题。在每种情况下,开发人员都需要评估是否可以在不导致成本超支或产品交付延迟的情况下对软件进行更改。需要记录不解决问题的影响,并与客户和高级经理共享,他们可能决定取消项目,而不是投入交付最终项目所需的资源。

It is important, even for projects using agile process models, to use an issue tracking or bug reporting system (e.g., Bugzilla2 or Jira3) to capture the testing results. This allows developers to record test failures and makes it easier to identify the test cases that will need to be run again to verify that a repair properly corrects the problem that was uncovered. In each case the developers need to assess whether the changes can be made to the software without causing a cost overrun or late product delivery. The implications of not fixing a problem need to be documented and shared with both the customer and senior managers who may decide to cancel the project rather than committing the resources needed to deliver the final project.

作为项目事后分析的一部分,开发人员和利益相关者应记录并考虑从创建候选版本中获得的问题和经验教训。在决定对软件产品向用户社区发布后进行未来开发之前,应考虑此信息。从当前产品中吸取的经验教训可以帮助开发人员对未来的类似项目做出更好的成本和时间估算。

The issues and lessons learned from creating the release candidate should be documented and considered by the developers and stakeholders as part of the project postmortem. This information should be considered before deciding to undertake future development of a software product following its release to the user community. The lessons learned from the current product can help developers make better cost and time estimates for similar projects in the future.

第 12 章和20章讨论了进行用户验收测试的技术。第 17 章对软件质量保证进行了更详细的讨论。

Techniques for conducting user acceptance testing are discussed in Chapters 12 and 20. A more detailed discussion on software quality assurance is presented in Chapter 17.

第70页

Page 70

4.9 维护发布软件

4.9 Maintain Release Software

维护被定义为在最终用户环境中接受并交付(发布)软件后保持软件运行所需的活动。维护将在软件产品的整个生命周期内持续进行。一些软件工程师认为,花在软件产品上的大部分钱将花在维护活动上。纠正性维护是对软件进行的反应性修改,以修复软件交付给客户的最终用户后发现的问题。适应性维护是软件交付后的反应性修改,以保持软件在不断变化的最终用户环境中可用。完美维护是指在交付后对软件进行主动修改,以提供新的用户功能、更好的程序代码结构或改进的文档。预防性维护是指在交付后对软件进行主动修改,以在现场用户发现产品故障之前检测并纠正产品故障 [SWEBOK 4 ]。可以安排和计划主动维护。反应性维护通常被描述为救火,因为对于对最终用户活动的成功至关重要的软件系统来说,它无法进行规划,并且必须立即进行处理。图 4.5显示开发人员通常只有 21% 的时间花在纠正性维护上。

Maintenance is defined as the activities needed to keep software operational after it has been accepted and delivered (released) in the end-user environment. Maintenance will continue for the life of the software product. Some software engineers believe that the majority of the money spent on a software product will be spent on maintenance activities. Corrective maintenance is the reactive modification of software to repair problems discovered after the software has been delivered to a customer’s end user. Adaptive maintenance is reactive modification of software after delivery to keep the software usable in a changing end-user environment. Perfective maintenance is the proactive modification of the software after delivery to provide new user features, better program code structure, or improved documentation. Preventive maintenance is the proactive modification of the software after delivery to detect and correct product faults before they are discovered by users in the field [SWEBOK4]. Proactive maintenance can be scheduled and planned for. Reactive maintenance is often described as firefighting because it cannot be planned for and must be attended immediately for software systems that are critical to the success of the end-users’ activities. Figure 4.5 shows that only 21 percent of the developers’ time is typically spent on corrective maintenance.

4.5维护 工作量分布

Figure 4.5 Distribution of maintenance effort

对于本章中描述的敏捷演化过程模型,开发人员通过创建每个增量原型来发布可工作的部分解决方案。随着新功能被添加到不断发展的软件系统中,所做的大部分工程工作都是预防性或完美维护。人们很容易认为维护工作只需计划绕螺旋线进行另一次旅行即可完成。但软件问题并不总是可以预见的,因此可能需要快速进行修复,并且开发人员在尝试修复损坏的软件时可能会想走捷径。开发人员可能不想花时间进行风险评估或规划。然而,如果不考虑解决一个问题所需的更改可能会给程序的其他部分带来新问题的可能性,那么开发人员就无法对软件进行更改。第71页

For an agile evolutionary process model like the one described in this chapter, developers release working partial solutions with the creation of each incremental prototype. Much of the engineering work done is preventive or perfective maintenance as new features are added to the evolving software system. It is tempting to think that maintenance is handled simply by planning to make another trip around the spiral. But software problems cannot always be anticipated, so repairs may need to be made quickly and developers may be tempted to cut corners when trying to repair the broken software. Developers may not want to spend time on risk assessment or planning. Yet, developers cannot afford to make changes to software without considering the possibility that the changes required to fix one problem will cause new problems to other portions of the program.Page 71

在更改程序代码之前了解该程序代码非常重要。如果开发人员已经记录了代码,那么其他人是否需要进行维护工作就会更容易理解。如果软件被设计为可扩展的,除了紧急缺陷修复之外,维护也可能更容易完成。必须仔细测试修改后的软件,以确保软件更改达到预期效果,并且不会在其他地方破坏软件。

It is important to understand the program code before making changes to it. If developers have documented the code, it will be easier to understand if other people need to do the maintenance work. If the software is designed to be extended, maintenance may also be accomplished more easily, other than emergency defect repairs. It is essential to test the modified software carefully to ensure software changes have their intended effect and do not break the software in other places.

创建易于支持和易于维护的软件产品的任务需要仔细和深思熟虑的工程设计。第 27 章对软件交付后的维护和支持任务进行了更详细的讨论。

The task of creating software products that are easy to support and easy to maintain requires careful and thoughtful engineering. A more detailed discussion on the task of maintaining and supporting software after delivery is presented in Chapter 27.

第72页

Page 72

4.10 总结

4.10 Summary

每个项目都是独一无二的,每个开发团队都由独特的个人组成。每个软件项目都需要一个路线图,并且开发软件的过程需要一组可预测的基本任务(沟通、规划、建模、构建和部署)。然而,这些任务不应单独执行,可能需要进行调整以满足每个新项目的需求。在本章中,我们建议使用高度交互的增量原型制作过程。我们认为这比在进行任何编程之前制定严格的产品计划和大型文档更好。要求发生变化。利益相关者的意见和反馈应该在开发过程的早期和经常发生,以确保交付有用的产品。

Every project is unique, and every development team is made up of unique individuals. Every software project needs a road map, and the process of developing software requires a predictable set of basic tasks (communication, planning, modeling, construction, and deployment). However, these tasks should not be performed in isolation and may need to be adapted to meet the needs of each new project. In this chapter, we suggested the use of a highly interactive, incremental prototyping process. We think this is better than producing rigid product plans and large documents prior to doing any programming. Requirements change. Stakeholder input and feedback should occur early and often in the development process to ensure the delivery of useful product.

我们建议使用演进过程模型,强调利益相关者频繁参与增量软件原型的创建和评估。将需求工程工件限制为一组最小的有用文档和模型,可以尽早生成原型和测试用例。计划创建进化原型可以减少重复创建一次性原型所需的工作所损失的时间。在设计过程的早期使用纸质原型还有助于避免设计出不满足客户期望的产品。在开始实际开发之前正确进行架构设计对于避免进度延误和成本超支也很重要。

We suggest the use of an evolutionary process model that emphasizes frequent stakeholder involvement in the creation and evaluation of incremental software prototypes. Limiting requirements engineering artifacts to the set of minimal useful documents and models allows the early production of prototypes and test cases. Planning to create evolutionary prototypes reduces the time lost repeating the work needed to create throwaway prototypes. Making use of paper prototypes early in the design process can also help to avoid programming products that do not satisfy customer expectations. Getting the architectural design right before beginning actual development is also important to avoiding schedule slippage and cost overruns.

规划很重要,但应尽快完成,以避免延误开发的开始。开发人员应该对项目需要多长时间才能完成有一个总体了解,但他们需要认识到,在软件产品交付之前他们不可能了解所有项目需求。开发人员应该明智地避免超出当前原型规划范围的详细规划。开发人员和利益相关者应采用一种流程来添加要在未来原型中实现的功能,并评估这些更改对项目进度和预算的影响。

Planning is important but should be done expeditiously to avoid delaying the start of development. Developers should have a general idea about how long a project will take to complete, but they need to recognize that they are not likely to know all the project requirements until the software products are delivered. Developers would be wise to avoid detailed planning that extends beyond planning the current prototype. The developers and stakeholders should adopt a process for adding features to be implemented in future prototypes and to assess the impact of these changes on the project schedule and budget.

风险评估和验收测试是原型评估过程的重要组成部分。拥有管理需求和向最终产品添加新功能的敏捷理念也很重要。开发人员在渐进式流程模型方面面临的最大挑战是管理范围蔓延,同时交付满足客户期望的产品,并在按时、在预算范围内交付产品的同时完成所有这一切。这就是软件工程如此具有挑战性和回报性的原因。

Risk assessment and acceptance testing are an important part of the prototype assessment process. Having an agile philosophy about managing requirements and adding new features to the final product is important as well. The biggest challenges developers have with evolutionary process models is managing scope creep while delivering a product that meets customer expectations and doing all this while delivering the product on time and within budget. That’s what makes software engineering so challenging and rewarding.

问题与思考点

Problems and Points to Ponder

4.1. 极限编程 (XP) 模型在处理增量原型方面与螺旋模型有何不同?

4.1. How does the Extreme Programming (XP) model differ from the spiral model in its treatment of incremental prototypes?

4.2. 编写用户故事的接受标准,描述您为第 3 章中的问题 3.7编写的大多数 Web 浏览器上的“最喜欢的地方”或“最喜欢的”功能的使用。

4.2. Write the acceptance criteria for the user story that describe the use of the “favorite places” or “favorites” feature found on most Web browsers that you wrote for Problem 3.7 in Chapter 3.

4.3. 您将如何为移动应用程序的第一个原型创建初步架构设计,以便您在设备上创建和保存购物清单?

4.3. How would you create a preliminary architectural design for the first prototype for a mobile app that lets you create and save a shopping list on your device?

4.4. 在编写原型之前,您从哪里可以获得估计原型中用户故事的开发时间所需的历史日期?

4.4. Where would you get the historic date needed to estimate the development time for the user stories in a prototype before it is written?

第73页4.5. 创建一系列草图,代表您在问题 4.3中创建的购物清单应用程序的纸质原型的关键屏幕。

Page 734.5. Create a series of sketches representing the key screens for a paper prototype for the shopping list app you created in Problem 4.3.

4.6. 如何测试为问题 4.5创建的纸质原型的可行性?

4.6. How can you test the viability of the paper prototype you created for Problem 4.5?

4.7. 在评估进化原型期间需要哪些数据点来做出进行或不进行的决定?

4.7. What data points are needed to make the go, no-go decision during the assessment of an evolutionary prototype?

4.8. 被动维护和主动维护有什么区别?

4.8. What is the difference between reactive and proactive maintenance?

1 Sprint(第 3.4 节)被描述为一个时间段,在此期间系统用户故事的子集将交付给产品所有者。

1 Sprint was described (Section 3.4) as a time period in which a subset of the system user stories will be delivered to the product owner.

2 https://www.bugzilla.org/。

2 https://www.bugzilla.org/.

3 https://www.atlassian.com/software/jira。

3 https://www.atlassian.com/software/jira.

4 SWEBOK 是指软件工程知识体系,可以通过以下链接访问:https://www.computer.org/web/swebok/v3。

4 SWEBOK refers to the Software Engineering Body of Knowledge, which can be accessed using the following link: https://www.computer.org/web/swebok/v3.

第74页

Page 74

章节

chapter

5软件工程的人性化

5 Human Aspects of Software Engineering

在IEEE Software的一期特刊中,客座编辑 [deS09] 做出了以下观察:

In a special issue of IEEE Software, the guest editors [deS09] make the following observation:

软件工程拥有大量旨在改进软件开发过程和最终产品的技术、工具和方法。然而,软件不仅仅是以适当的技术方式应用适当的技术解决方案的产品。软件是由人开发、由人使用、支持人与人之间的交互的。因此,人类特征、行为和合作是实际软件开发的核心。

Software engineering has an abundance of techniques, tools, and methods designed to improve both the software development process and the final product. However, software isn’t simply a product of the appropriate technical solutions applied in appropriate technical ways. Software is developed by people, used by people, and supports interaction among people. As such, human characteristics, behavior, and cooperation are central to practical software development.

如果没有一支技术精湛且积极进取的团队,成功是不可能的。

Without a team of skilled and motivated people, success is unlikely.

第75页

Page 75

5.1 软件工程师的特征

5.1 Characteristics of a Software Engineer

那么你想成为一名软件工程师吗?显然,您需要掌握技术知识,学习理解问题所需的技能,设计有效的解决方案,构建软件并对其进行测试,以便开发出尽可能高质量的产品。您需要管理变更、与利益相关者沟通并根据需要使用适当的工具。我们将在本书后面详细讨论这些事情。

So you want to be a software engineer? Obviously, you need to master the technical stuff, learn the skills required to understand the problem, design an effective solution, build the software, and test it in an effort to develop the highest-quality products possible. You need to manage change, communicate with stakeholders, and use appropriate tools as needed. We will discuss these things at great length later in this book.

但还有其他同样重要的事情——人的因素将使你成为一名高效的软件工程师。Erasmus [Era09] 确定了软件工程师表现出“超级专业”行为时出现的七个特征。

But there are other things that are equally important—the human aspects that will make you effective as a software engineer. Erasmus [Era09] identifies seven traits that are present when a software engineer exhibits “superprofessional” behavior.

一名高效的软件工程师具有个人责任感。这意味着她有动力兑现对同事、利益相关者和管理层的承诺。这意味着她会做需要做的事情,当需要付出压倒一切的努力来取得成功的结果时。

An effective software engineer has a sense of individual responsibility. This implies a drive to deliver on her promises to peers, stakeholders, and her management. It implies that she will do what needs to be done, when it needs to be done in an overriding effort to achieve a successful outcome.

一名高效的软件工程师能够敏锐地意识到其他团队成员、要求更改现有软件解决方案的利益相关者以及对项目进行全面控制的经理的需求。他观察人们工作的环境,并调整自己的行为以将两者考虑在内。

An effective software engineer has an acute awareness of the needs of other team members, the stakeholders requesting changes to an existing software solution, and the managers who have overall control of the project. He observes the environment in which people work and adapts his behavior to take both into account.

一位高效的软件工程师是极其诚实的。如果她发现设计有缺陷,她会以建设性但诚实的方式指出这些缺陷。如果被要求歪曲有关时间表、功能、性能或其他产品或项目特征的事实,她会选择现实和诚实。

An effective software engineer is brutally honest. If she sees a flawed design, she points out the flaws in a constructive but honest manner. If asked to distort facts about schedules, features, performance, or other product or project characteristics, she opts to be realistic and truthful.

一名高效的软件工程师在压力下表现出韧性。软件工程总是处于混乱的边缘。压力有多种形式——需求和优先级的变化、要求严格的利益相关者以及专横的管理者。一位高效的软件工程师会管理压力,以免其绩效受到影响。

An effective software engineer exhibits resilience under pressure. Software engineering is always on the edge of chaos. Pressure comes in many forms—changes in requirements and priorities, demanding stakeholders, and overbearing managers. An effective software engineer manages pressure so that his performance does not suffer.

一名高效的软件工程师具有高度的公平感。她很高兴与同事分享功劳。她尽力避免利益冲突,并且从不采取破坏他人工作的行为。

An effective software engineer has a heightened sense of fairness. She gladly shares credit with her colleagues. She tries to avoid conflicts of interest and never acts to sabotage the work of others.

一位高效的软件工程师表现出对细节的关注。这并不意味着对完美的痴迷。在做出日常技术决策时,他会仔细考虑为产品和项目制定的更广泛的标准(例如性能、成本、质量)。

An effective software engineer exhibits attention to detail. This does not imply an obsession with perfection. He carefully considers the broader criteria (e.g., performance, cost, quality) that have been established for the product and the project in making his daily technical decisions.

最后,一个有效的软件工程师是务实的。她认识到软件工程不是一种必须遵循教条规则的宗教,而是一种可以根据当前情况进行调整的学科。

Finally, an effective software engineer is pragmatic. She recognizes that software engineering is not a religion in which dogmatic rules must be followed, but rather a discipline that can be adapted based on the circumstances at hand.

第76页

Page 76

5.2 软件工程心理学

5.2 The Psychology of Software Engineering

在一篇关于软件工程心理学的开创性论文中,Bill Curtis 和 Diane Walz [Cur90] 提出了软件开发的分层行为模型(图 5.1)。在个人层面上,软件工程心理学侧重于对要解决的问题的认识、解决问题所需的解决问题的技能以及在模型外层建立的约束内完成解决方案的动机。在团队和项目层面,团队动力成为主导因素。在这里,团队结构和社会因素决定着成功。团队沟通、协作和协调与单个团队成员的技能同样重要。在外层,组织行为控制着公司的行为及其对商业环境的反应。

In a seminal paper on the psychology of software engineering, Bill Curtis and Diane Walz [Cur90] suggest a layered behavioral model for software development (Figure 5.1). At an individual level, software engineering psychology focuses on recognition of the problem to be solved, the problem-solving skills required to solve it, and the motivation to complete the solution within the constraints established by outer layers in the model. At the team and project levels, group dynamics becomes the dominating factor. Here, team structure and social factors govern success. Group communication, collaboration, and coordination are as important as the skills of an individual team member. At the outer layers, organizational behavior governs the actions of the company and its response to the business milieu.

图5.1 软件工程的分层行为模型(改编自 [Cur90]

Figure 5.1 A layered behavioral model for software engineering (adapted from [Cur90])

资料来源:改编自 Curtis、Bill 和 Walz、Diane,“大规模编程心理学:团队和组织行为”,编程心理学,学术出版社,1990 年。

Source: Adapted from Curtis, Bill, and Walz, Diane, “The Psychology of Programming in the Large: Team and Organizational Behavior,” Psychology of Programming, Academic Press, 1990.

5.3 软件团队

5.3 The Software Team

Tom DeMarco 和 Tim Lister [DeM98]在他们的经典著作Peopleware中讨论了软件团队的凝聚力:

In their classic book Peopleware, Tom DeMarco and Tim Lister [DeM98] discuss the cohesiveness of a software team:

在商业世界中,我们倾向于宽松地使用团队这个词,将任何被分配一起工作的人称为“团队”。但其中许多团体的行为方式并不像团队。他们可能没有成功的共同定义或任何可识别的团队精神。缺少的是一种我们称之为果冻的现象。

We tend to use the word team loosely in the business world, calling any group of people assigned to work together a “team.” But many of these groups just don’t behave like teams. They may not have a common definition of success or any identifiable team spirit. What is missing is a phenomenon that we call jell.

凝聚的团队是一群紧密团结在一起的人,整体大于各个部分的总和。。。。

A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. . . .

一旦团队开始凝聚,成功的可能性就会大大增加。团队可以变得势不可挡,成为成功的主宰。。。。他们不需要用传统的方式来管理,当然也不需要激励。他们有动力。

Once a team begins to jell, the probability of success goes way up. The team can become unstoppable, a juggernaut for success. . . . They don’t need to be managed in the traditional way, and they certainly don’t need to be motivated. They’ve got momentum.

第77页德马科和李斯特认为,凝胶团队的成员比平均水平显着提高生产力和积极性。他们有着共同的目标、共同的文化,而且在很多情况下,还有一种“精英意识”,这使他们独一无二。

Page 77DeMarco and Lister contend that members of jelled teams are significantly more productive and more motivated than average. They share a common goal, a common culture, and in many cases, a “sense of eliteness” that makes them unique.

没有万无一失的方法来创建一支团结的团队。但有效的软件团队通常具有一些特征。1 Miguel Carrasco [Car08] 建议一个有效的软件团队必须建立一种使命感。一个有效的团队还必须灌输一种参与感,让每个成员都感到他的技能和贡献受到重视。

There is no foolproof method for creating a jelled team. But there are attributes that are normally found in effective software teams.1 Miguel Carrasco [Car08] suggests that an effective software team must establish a sense of purpose. An effective team must also inculcate a sense of involvement that allows every member to feel that his skill set and contributions are valued.

一个有效的团队应该培养信任感。团队中的软件工程师应该信任同事和经理的技能和能力。团队应该通过定期反思其软件工程方法并寻找改进工作的方法来鼓励改进意识。

An effective team should foster a sense of trust. Software engineers on the team should trust the skills and competence of their peers and their managers. The team should encourage a sense of improvement, by periodically reflecting on its approach to software engineering and looking for ways to improve their work.

最有效的软件团队是多元化的,因为他们结合了各种不同的技能。高技能的技术专家得到了技术背景较少但更能理解利益相关者需求的成员的补充。

The most effective software teams are diverse in the sense that they combine a variety of different skill sets. Highly skilled technologists are complemented by members who may have less technical background but are more empathetic to the needs of stakeholders.

但并不是所有的团队都是有效的,也不是所有的团队都是果冻的。事实上,许多团队都遭受着 Jackman [Jac98] 所说的“团队毒性”。她定义了“营造潜在有毒团队环境”的五个因素:(1)疯狂的工作氛围,(2)导致团队成员之间摩擦的高度挫败感,(3)“支离破碎或协调不善”的软件流程,(4)软件团队中的角色定义不明确,以及(5)“持续且反复地面临失败”。

But not all teams are effective and not all teams jell. In fact, many teams suffer from what Jackman [Jac98] calls “team toxicity.” She defines five factors that “foster a potentially toxic team environment”: (1) a frenzied work atmosphere, (2) high frustration that causes friction among team members, (3) a “fragmented or poorly coordinated” software process, (4) an unclear definition of roles on the software team, and (5) “continuous and repeated exposure to failure.”

为了避免疯狂的工作环境,团队应该能够访问完成工作所需的所有信息。主要目标一旦确定,除非绝对必要,否则不应修改。如果软件团队被赋予尽可能多的决策责任,就可以避免挫败感。通过了解要构建的产品和执行工作的人员并允许团队选择流程模型,可以避免不适当的流程(例如,不必要或繁重的工作任务或选择不当的工作产品)。团队本身应该建立自己的问责机制(技术审查2是实现这一目标的绝佳方法),并在团队成员未能执行任务时定义一系列纠正方法。最后,避免失败氛围的关键是建立基于团队的反馈和问题解决技术。

To avoid a frenzied work environment, the team should have access to all information required to do the job. Major goals and objectives, once defined, should not be modified unless absolutely necessary. A software team can avoid frustration if it is given as much responsibility for decision making as possible. An inappropriate process (e.g., unnecessary or burdensome work tasks or poorly chosen work products) can be avoided by understanding the product to be built and the people doing the work and by allowing the team to select the process model. The team itself should establish its own mechanisms for accountability (technical reviews2 are an excellent way to accomplish this) and define a series of corrective approaches when a member of the team fails to perform. And finally, the key to avoiding an atmosphere of failure is to establish team-based techniques for feedback and problem solving.

除了杰克曼描述的五种毒素之外,软件团队还经常面临其成员不同的人类特征的困扰。有些人凭直觉收集信息,从不同的事实中提取广泛的概念。其他人则线性地处理信息,从提供的数据中收集和组织微小的细节。有些团队成员只有在提出逻辑、有序的论点时才愿意做出决定。其他人则凭直觉,愿意根据“感觉”做出决定。有些人在里程碑日期之前就努力工作,以便在日期临近时避免压力,而另一些人则因急于在最后一刻截止日期而感到精力充沛。认识到人与人之间的差异以及本节中介绍的其他指导方针,可以提高创建团结团队的可能性。

In addition to the five toxins described by Jackman, a software team often struggles with the differing human traits of its members. Some people gather information intuitively, distilling broad concepts from disparate facts. Others process information linearly, collecting and organizing minute details from the data provided. Some team members are comfortable making decisions only when a logical, orderly argument is presented. Others are intuitive, willing to make a decision based on “feel.” Some work hard to get things done long before a milestone date, thereby avoiding stress as the date approaches, while others are energized by the rush to make a last-minute deadline. Recognition of human differences, along with other guidelines presented in this section, provide a higher likelihood of creating teams that jell.

第78页

Page 78

5.4 团队结构

5.4 Team Structures

“最佳”团队结构取决于组织的管理风格、团队人数及其技能水平以及整体问题的难度。Mantei [Man81] 描述了在规划软件工程团队结构时应考虑的许多项目因素:(1)要解决的问题的难度,(2)最终程序的“规模”代码或功能点,3 (3) 团队在一起的时间(团队生命周期),(4) 问题可以模块化的程度,(5) 所构建系统所需的质量和可靠性,(6)交付日期的严格性,以及(7)项目所需的社交(沟通)程度。

The “best” team structure depends on the management style of your organization, the number of people who will populate the team and their skill levels, and the overall problem difficulty. Mantei [Man81] describes a number of project factors that should be considered when planning the structure of software engineering teams: (1) difficulty of the problem to be solved, (2) “size” of the resultant program(s) in lines of code or function points,3 (3) time that the team will stay together (team lifetime), (4) degree to which the problem can be modularized, (5) required quality and reliability of the system to be built, (6) rigidity of the delivery date, and (7) degree of sociability (communication) required for the project.

在过去的十年中,敏捷软件开发(第 3 章)被认为是解决困扰软件项目工作的许多问题的解药。敏捷哲学鼓励客户满意度和软件的早期增量交付、积极主动的小型项目团队、非正式的方法、最少的软件工程工作产品以及整体开发的简单性。

Over the past decade, agile software development (Chapter 3) has been suggested as an antidote to many of the problems that have plagued software project work. The agile philosophy encourages customer satisfaction and early incremental delivery of software, small highly motivated project teams, informal methods, minimal software engineering work products, and overall development simplicity.

一个小型的、积极性很高的项目团队,也称为敏捷团队,采用了第 5.3 节中讨论的成功软件项目团队的许多特征,并避免了许多产生问题的毒素。然而,敏捷哲学强调个人(团队成员)的能力,并将团队协作作为团队成功的关键因素。将创造力引入高绩效团队必须是软件工程组织的中心目标。Cockburn 和 Highsmith [Coc01a] 认为,“优秀”的软件人员可以在任何软件流程的框架内工作,而表现不佳的人员无论如何都会陷入困境。他们认为,底线是“人胜过流程”,但即使是好人也会受到不明确的流程和不良资源支持的阻碍。我们同意。

A small, highly motivated project team, also called an agile team, adopts many of the characteristics of successful software project teams discussed in Section 5.3 and avoids many of the toxins that create problems. However, the agile philosophy stresses individual (team member) competency, coupled with group collaboration as critical success factors for the team. Channeling creative energy into a high-performance team must be a central goal of a software engineering organization. Cockburn and Highsmith [Coc01a] suggest that “good” software people can work within the framework of any software process, and weak performers will struggle regardless. The bottom line, they contend, is that “people trump process” but that even good people can be hampered by an ill-defined process and poor resource support. We agree.

为了有效利用每个团队成员的能力并通过软件项目促进有效的协作,敏捷团队是自组织的。自组织团队不一定维持单一的团队结构。团队对其结构进行必要的更改,以响应开发环境的变化或不断发展的工程问题解决方案的变化。

To make effective use of the competencies of each team member and to foster effective collaboration through a software project, agile teams are self-organizing. A self-organizing team does not necessarily maintain a single team structure. The team makes the changes needed to its structure to respond to the changes in the development environment or changes in the evolving engineering problem solution.

团队成员和所有项目利益相关者之间的沟通至关重要。敏捷团队通常有客户代表作为团队成员。这促进了开发人员和利益相关者之间的尊重,并为不断发展的产品提供及时、频繁的反馈的途径。第79页

Communication between team members and all project stakeholders is essential. Agile teams often have customer representatives as team members. This fosters respect among the developers and stakeholders, as well as providing avenues for timely and frequent feedback on the evolving products.Page 79

5.5 社交媒体的影响

5.5 The Impact of Social Media

电子邮件、短信和视频会议已成为软件工程工作中无处不在的活动。但这些沟通机制实际上只不过是现代面对面接触的替代品或补充。社交媒体则不同。

E-mail, texting, and videoconferencing have become ubiquitous activities in software engineering work. But these communication mechanisms are really nothing more than modern substitutes or supplements for the face-to-face contact. Social media is different.

Begel [Beg10] 和他的同事在讨论社交媒体在软件工程中的发展和应用时写道:

Begel [Beg10] and his colleagues address the growth and application of social media in software engineering when they write:

围绕软件开发的社会过程是。。。高度依赖工程师的能力,以找到具有相似目标和互补技能的个人并与他们联系,协调每个团队成员的沟通和团队偏好,在整个软件生命周期中进行协作和协调,并倡导其产品在市场上取得成功。

The social processes around software development are . . . highly dependent on engineers’ abilities to find and connect with individuals who share similar goals and complementary skills, to harmonize each team member’s communication and teaming preferences, to collaborate and coordinate during the entire software lifecycle, and advocate for their product’s success in the marketplace.

在某些方面,这种“联系”可能与面对面的交流一样重要。社交媒体的价值随着团队规模的扩大而增长,并且当团队地理分散时,社交媒体的价值会进一步放大。

In some ways, this “connection” can be as important as face-to-face communication. The value of social media grows as team size increases and is magnified further when the team is geographically dispersed.

社交网络工具(例如 Facebook、LinkedIn、Slack、Twitter)允许软件开发人员和相关技术人员之间建立一定程度的分离联系。这使得社交网站上的“朋友”能够了解可能拥有与应用领域或要解决的问题相关的知识或专业知识的朋友的朋友。可以在组织内使用基于社交网络范式构建的专用专用网络。

Social networking tools (e.g., Facebook, LinkedIn, Slack, Twitter) allow degrees-of-separation connections among software developers and related technologists. This allows “friends” on a social networking site to learn about friends of friends who may have knowledge or expertise related to the application domain or problem to be solved. Specialized private networks built on the social networking paradigm can be used within an organization.

第80页需要注意的是,在使用社交媒体进行软件工程工作时,不应忽视隐私和安全问题。软件工程师所做的大部分工作可能是其雇主专有的,泄露可能会非常有害。因此,必须权衡社交媒体的独特优势与不受控制地披露私人信息的威胁。

Page 80It is very important to note that privacy and security issues should not be overlooked when using social media for software engineering work. Much of the work performed by software engineers may be proprietary to their employer and disclosure could be very harmful. For that reason, the distinct benefits of social media must be weighed against the threat of uncontrolled disclosure of private information.

5.6 全球团队

5.6 Global Teams

在软件领域,全球化不仅仅意味着跨越国界的商品和服务转移。在过去的几十年里,越来越多的主要软件产品是由通常位于不同国家的软件团队构建的。这些全球软件开发 (GSD) 团队面临着独特的挑战,包括协调、协作、沟通和专业决策。协调、协作和沟通的方法受到已建立的团队结构的影响。所有软件团队的决策都因四个因素而变得复杂[Gar10a]:

In the software domain, globalization implies more than the transfer of goods and services across international boundaries. For the past few decades, an increasing number of major software products have been built by software teams that are often located in different countries. These global software development (GSD) teams have unique challenges that include coordination, collaboration, communication, and specialized decision making. Approaches to coordination, collaboration, and communication are influenced by the team structure that has been established. Decision making on all software teams is complicated by four factors [Gar10a]:

  • 问题的复杂性。

  • Complexity of the problem.

  • 与决策相关的不确定性和风险。

  • Uncertainty and risk associated with the decision.

  • 意外后果法则(即与工作相关的决策对另一个项目目标产生意外影响)。

  • The law of unintended consequences (i.e., a work-associated decision has an unintended effect on another project objective).

  • 对问题的不同看法导致对前进方向的不同结论。

  • Different views of the problem that lead to different conclusions about the way forward.

对于 GSD 团队来说,与协调、协作和沟通相关的挑战可能会对决策产生深远的影响。图 5.2说明了距离对 GSD 团队面临的挑战的影响。距离使沟通变得复杂,但同时也凸显了协调的必要性。距离还带来了文化差异造成的障碍和复杂性。障碍和复杂性会削弱通信(即信噪比降低)。这种动态中固有的问题可能会导致项目变得不稳定。

For a GSD team, the challenges associated with coordination, collaboration, and communication can have a profound effect on decision making. Figure 5.2 illustrates the impact of distance on the challenges that face a GSD team. Distance complicates communication, but, at the same time, accentuates the need for coordination. Distance also introduces barriers and complexity that can be driven by cultural differences. Barriers and complexity attenuate communication (i.e., the signal-to-noise ratio decreases). The problems inherent in this dynamic can result in a project that becomes unstable.

图5.2 影响 GSD 团队的因素

Figure 5.2 Factors affecting a GSD team

第81页

Page 81

5.7 总结

5.7 Summary

一个成功的软件工程师必须具备技术技能。但除此之外,他还必须对自己的承诺负责,了解同事的需求,诚实地评估产品和项目,在压力下保持弹性,公平对待同事,并表现出对细节的关注。

A successful software engineer must have technical skills. But, in addition, he must take responsibility for his commitments, be aware of the needs of his peers, be honest in his assessment of the product and the project, be resilient under pressure, treat his peers fairly, and exhibit attention to detail.

软件工程心理学包括个体认知和动机、软件团队的群体动力以及公司的组织行为。一个成功的(“凝结的”)软件团队比平均水平更有生产力和积极性。为了高效,软件团队必须有使命感、参与感、信任感和改进感。此外,团队必须避免“毒性”,其特征是疯狂和令人沮丧的工作氛围、不适当的软件流程、软件团队中角色定义不明确以及持续失败。

The psychology of software engineering includes individual cognition and motivation, the group dynamics of a software team, and the organizational behavior of the company. A successful (“jelled”) software team is more productive and motivated than average. To be effective, a software team must have a sense of purpose, a sense of involvement, a sense of trust, and a sense of improvement. In addition, the team must avoid “toxicity” that is characterized by a frenzied and frustrating work atmosphere, an inappropriate software process, an unclear definition of roles on the software team, and continuous exposure to failure.

敏捷团队遵循敏捷理念,通常比具有严格成员角色和外部管理控制的传统软件团队拥有更多的自主权。敏捷团队强调沟通、简单、反馈、勇气和尊重。

Agile teams subscribe to the agile philosophy and generally have more autonomy than more conventional software teams with rigid member roles and external management control. Agile teams emphasize communication, simplicity, feedback, courage, and respect.

社交媒体工具正在成为许多软件项目不可或缺的一部分,提供增强软件团队沟通和协作的服务。社交媒体和电子通信对于全球软件开发特别有用,因为地理隔离可能会阻碍软件工程的成功。

Social media tools are becoming an integral part of many software projects, providing services that enhance communication and collaboration for a software team. Social media and electronic communication are particularly useful for global software development where geographic separation can precipitate barriers to successful software engineering.

问题与思考点

Problems and Points to Ponder

5.1. 根据您对优秀软件开发人员的个人观察,请说出他们中常见的三种性格特征。

5.1. Based on your personal observation of people who are excellent software developers, name three personality traits that appear to be common among them.

5.2. 你怎样才能“极其诚实”而又不被(其他人)认为是侮辱性的或具有攻击性的?

5.2. How can you be “brutally honest” and still not be perceived (by others) as insulting or aggressive?

5.3. 软件团队如何构建“人为边界”来降低他们与他人沟通的能力?

5.3. How does a software team construct “artificial boundaries” that reduce their ability to communicate with others?

5.4. 编写一个场景,其中SafeHome团队成员使用一种或多种形式的社交媒体作为其软件项目的一部分。

5.4. Write a scenario in which the SafeHome team members make use of one or more forms of social media as part of their software project.

5.5. 参见图5.2,为什么距离使通信变得复杂?为什么距离会凸显协调的必要性?距离会带来哪些类型的障碍和复杂性?

5.5. Referring to Figure 5.2, why does distance complicate communication? Why does distance accentuate the need for coordination? What types of barriers and complexities are introduced by distance?

1 Bruce Tuckman 观察到,成功的团队在提高生产力的过程中要经历四个阶段(组建、激荡、规范和执行)(http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development)。

1 Bruce Tuckman observes that successful teams go through four phases (forming, storming, norming, and performing) on their way to becoming productive (http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development).

2第 16 章详细讨论了技术审查。

2 Technical reviews are discussed in detail in Chapter 16.

3代码行 (LOC) 和功能点是计算机程序大小的度量,将在第 24 章中讨论。

3 Lines of code (LOC) and function points are measures of the size of a computer program and are discussed in Chapter 24.

第83页

Page 83

部分 造型

PART Two Modeling

在软件工程:从业者方法的这一部分中,您将了解用于创建高质量需求和设计模型的原理、概念和方法。这些问题将在以下章节中讨论:

In this part of Software Engineering: A Practitioner’s Approach, you’ll learn about the principles, concepts, and methods that are used to create high-quality requirements and design models. These questions are addressed in the chapters that follow:

  • 哪些概念和原则指导软件工程实践?

  • What concepts and principles guide software engineering practice?

  • 什么是需求工程?实现良好需求分析的基本概念是什么?

  • What is requirements engineering, and what are the underlying concepts that lead to good requirements analysis?

  • 需求模型是如何创建的,它的元素是什么?

  • How is the requirements model created, and what are its elements?

  • 好的设计的要素是什么?

  • What are the elements of a good design?

  • 建筑设计如何为所有其他设计行为建立框架,以及使用哪些模型?

  • How does architectural design establish a framework for all other design actions, and what models are used?

  • 我们如何设计高质量的软件组件?

  • How do we design high-quality software components?

  • 在设计用户体验时应用了哪些概念、模型和方法?

  • What concepts, models, and methods are applied as the user experience is designed?

  • 什么是基于模式的设计?

  • What is pattern-based design?

  • 使用哪些专门的策略和方法来设计移动应用程序?

  • What specialized strategies and methods are used to design mobile apps?

一旦回答了这些问题,您就可以更好地准备应用软件工程实践。

Once these questions are answered, you’ll be better prepared to apply software engineering practice.

第84页

Page 84

章节

chapter

6指导实践的原则

6 Principles That Guide Practice

软件工程师通常被描述为独自长时间工作,以在不可能的期限内完成任务,而无需与其他人联系。可以肯定的是,这是软件工程实践的一个黑暗形象。然而,正如我们在前面的章节中讨论的那样,大多数软件工程师都是团队工作,并经常与利益相关者互动。如果您在互联网上搜索技术专业人员的调查,您会发现软件工程师被列为对工作满意度最高的人之一。

Software engineers are often depicted as working long hours by themselves to meet impossible deadlines without connecting to other people. This is a dark image of software engineering practice to be sure. Yet, as we discussed in the previous chapters, most software engineers work on teams and frequently interact with their stakeholders. If you search for surveys of technical professionals on the Internet, you will see software engineers listed among those experiencing the greatest satisfaction from their jobs.

第85页创建计算机软件的人们实践的是软件工程的艺术、工艺或学科1 。但什么是软件工程“实践”呢?从一般意义上讲,实践是软件工程师每天调用的概念、原理、方法和工具的集合。实践使管理者能够管理软件项目,软件工程师能够构建计算机程序。实践用完成工作所需的技术和管理方法来填充软件过程模型。实践将杂乱无章的方法转变为更有组织、更有效、更有可能取得成功的方法。

Page 85People who create computer software practice the art or craft or discipline1 that is software engineering. But what is software engineering “practice”? In a generic sense, practice is a collection of concepts, principles, methods, and tools that a software engineer calls upon on a daily basis. Practice allows managers to manage software projects and software engineers to build computer programs. Practice populates a software process model with the necessary technical and management how-to’s to get the job done. Practice transforms a haphazard unfocused approach into something that is more organized, more effective, and more likely to achieve success.

本书的其余部分将探讨软件工程实践的各个方面。在本章中,我们的重点是指导软件工程实践的原则和概念。

Various aspects of software engineering practice will be examined throughout the remainder of this book. In this chapter, our focus is on principles and concepts that guide software engineering practice in general.

6.1 核心原则

6.1 Core Principles

软件工程以一系列核心原则为指导,这些原则有助于应用有意义的软件过程和执行有效的软件工程方法。在过程层面,核心原则建立了一个哲学基础,指导软件团队执行框架和伞式活动并生成一组软件工程工作产品。在实践层面,核心原则建立了一系列价值观和规则,可以指导您分析问题、设计解决方案、实施和测试解决方案,以及最终部署软件,以便利益相关者可以使用它。

Software engineering is guided by a collection of core principles that help in the application of a meaningful software process and the execution of effective software engineering methods. At the process level, core principles establish a philosophical foundation that guides a software team as it performs the framework and umbrella activities and produces a set of software engineering work products. At the practice level, core principles establish a collection of values and rules that can guide you in analyzing a problem, designing a solution, implementing and testing the solution, and ultimately deploying the software so stakeholders can use it.

6.1.1 指导流程的原则

6.1.1 Principles That Guide Process

在本书的第一部分中,我们讨论了软件过程的重要性,并描述了为软件工程工作提出的几种过程模型。每个项目都是独一无二的,每个团队都是独一无二的。这意味着您必须调整流程以最适合您的需求。无论您的团队采用哪种流程模型,它都包含我们在第 1 章中描述的通用流程框架的元素。以下一组核心原则可以应用于该框架和每个软件流程。该框架的简化视图如图 6.1所示。

In Part One of this book we discussed the importance of the software process and described several process models that have been proposed for software engineering work. Every project is unique, and every team is unique. That means you must adapt your process to best fit your needs. Regardless of the process model your team adopts, it contains elements of the generic process framework we described in Chapter 1. The following set of core principles can be applied to this framework and to every software process. A simplified view of this framework is shown in Figure 6.1.

图6.1简化 流程框架

Figure 6.1 Simplified process framework

原则 1.敏捷。无论您选择的流程模型是规范性的还是敏捷的,敏捷开发的基本原则都应该指导您的方法。您所做工作的每个方面都应强调行动的经济性——使您的技术方法尽可能简单,使您产生的工作产品尽可能简洁,并尽可能在本地做出决策。

Principle 1. Be agile. Whether the process model you choose is prescriptive or agile, the basic tenets of agile development should govern your approach. Every aspect of the work you do should emphasize economy of action—keep your technical approach as simple as possible, keep the work products you produce as concise as possible, and make decisions locally whenever possible.

原则2.每一步都注重质量。每个流程活动、操作和任务的退出条件应关注已生成的工作产品的质量。

Principle 2. Focus on quality at every step. The exit condition for every process activity, action, and task should focus on the quality of the work product that has been produced.

原则 3.做好适应的准备。过程不是宗教体验,教条在其中没有地位。必要时,根据问题、人员和项目本身施加的限制调整您的方法。

Principle 3. Be ready to adapt. Process is not a religious experience, and dogma has no place in it. When necessary, adapt your approach to constraints imposed by the problem, the people, and the project itself.

第86页原则 4.建立一支高效的团队。软件工程过程和实践很重要,但底线是人。建立一支相互信任和尊重的自组织团队。2

Page 86Principle 4. Build an effective team. Software engineering process and practice are important, but the bottom line is people. Build a self-organizing team that has mutual trust and respect.2

原则五:建立沟通协调机制。项目失败是因为重要信息落入裂缝和/或利益相关者未能协调他们的努力来创建成功的最终产品。这些都是管理问题,必须解决。

Principle 5. Establish mechanisms for communication and coordination. Projects fail because important information falls into the cracks and/or stakeholders fail to coordinate their efforts to create a successful end product. These are management issues, and they must be addressed.

原则 6.管理变革。该方法可以是正式的或非正式的,但必须建立机制来管理变更的请求、评估、批准和实施方式。

Principle 6. Manage change. The approach may be either formal or informal, but mechanisms must be established to manage the way changes are requested, assessed, approved, and implemented.

原则 7.评估风险。在开发软件的过程中,很多事情都可能出错。制定应急计划至关重要。其中一些应急计划将构成安全工程任务的基础(第 18 章)。

Principle 7. Assess risk. Lots of things can go wrong as software is being developed. It’s essential that you establish contingency plans. Some of these contingency plans will form the basis for security engineering tasks (Chapter 18).

原则 8.创建为他人提供价值的工作产品。仅创建那些为其他流程活动、操作或任务提供价值的工作产品。作为软件工程实践的一部分产生的每个工作产品都将被传递给其他人。确保工作产品提供必要的信息,没有歧义或遗漏。

Principle 8. Create work products that provide value for others. Create only those work products that provide value for other process activities, actions, or tasks. Every work product that is produced as part of software engineering practice will be passed on to someone else. Be sure that the work product imparts the necessary information without ambiguity or omission.

本书的第四部分重点关注项目和流程管理问题,并详细考虑每个原则的各个方面。

Part Four of this book focuses on project and process management issues and considers various aspects of each of these principles in some detail.

6.1.2 指导实践的原则

6.1.2 Principles That Guide Practice

软件工程实践有一个首要目标:按时交付高质量的可操作软件,其中包含满足所有利益相关者需求的功能和特性。为了实现这一目标,您应该采用一套指导您的技术工作的核心原则。无论您应用何种分析和设计方法、使用何种构建技术(例如编程语言、自动化工具)或选择何种验证和确认方法,这些原则都有其优点。以下一组核心原则是软件工程实践的基础:第87页

Software engineering practice has a single overriding goal: to deliver on-time, high-quality, operational software that contains functions and features that meet the needs of all stakeholders. To achieve this goal, you should adopt a set of core principles that guide your technical work. These principles have merit regardless of the analysis and design methods that you apply, the construction techniques (e.g., programming language, automated tools) that you use, or the verification and validation approach that you choose. The following set of core principles is fundamental to the practice of software engineering:Page 87

原则 1.分而治之。用更技术性的方式来说,分析和设计应该始终强调关注点分离(SoC)。如果将一个大问题细分为元素(或关注点)的集合,那么它会更容易解决。

Principle 1. Divide and conquer. Stated in a more technical manner, analysis and design should always emphasize separation of concerns (SoCs). A large problem is easier to solve if it is subdivided into a collection of elements (or concerns).

原则 2.理解抽象的使用。从本质上讲,抽象是对系统中某些复杂元素的简化,用于用单个短语传达含义。当我们使用抽象电子表格时,假设您了解电子表格是什么、电子表格所呈现的内容的一般结构以及可以应用于它的典型功能。在软件工程实践中,您使用许多不同级别的抽象,每个抽象级别都传递或暗示必须传达的含义。在分析和设计工作中,软件团队通常从代表高抽象级别的模型(例如电子表格)开始,然后慢慢将这些模型细化为较低抽象级别(例如列或SUM函数

Principle 2. Understand the use of abstraction. At its core, an abstraction is a simplification of some complex element of a system used to communicate meaning in a single phrase. When we use the abstraction spreadsheet, it is assumed that you understand what a spreadsheet is, the general structure of content that a spreadsheet presents, and the typical functions that can be applied to it. In software engineering practice, you use many different levels of abstraction, each imparting or implying meaning that must be communicated. In analysis and design work, a software team normally begins with models that represent high levels of abstraction (e.g., a spreadsheet) and slowly refines those models into lower levels of abstraction (e.g., a column or the SUM function).

原则 3.力求一致性。无论是创建分析模型、开发软件设计、生成源代码还是创建测试用例,一致性原则表明熟悉的上下文使软件更易于使用。例如,考虑移动应用程序的用户界面设计。菜单选项的一致放置、一致的配色方案的使用以及可识别图标的一致使用有助于创建高效的用户体验。

Principle 3. Strive for consistency. Whether it’s creating an analysis model, developing a software design, generating source code, or creating test cases, the principle of consistency suggests that a familiar context makes software easier to use. As an example, consider the design of a user interface for a mobile app. Consistent placement of menu options, the use of a consistent color scheme, and the consistent use of recognizable icons help to create a highly effective user experience.

原则4.注重信息传递。软件是关于信息传输的——从数据库到最终用户,从遗留系统到WebApp,从最终用户到图形用户界面(GUI),从操作系统到应用程序,从一个软件组件到另一个软件组件——这个清单几乎是无穷无尽的。在任何情况下,信息都会通过界面流动,这意味着有可能出现错误、遗漏或歧义。这个原则的含义是,必须特别关注接口的分析、设计、构建和测试。

Principle 4. Focus on the transfer of information. Software is about information transfer—from a database to an end user, from a legacy system to a WebApp, from an end user into a graphic user interface (GUI), from an operating system to an application, from one software component to another—the list is almost endless. In every case, information flows across an interface, and this means there are opportunities for errors, omissions, or ambiguity. The implication of this principle is that you must pay special attention to the analysis, design, construction, and testing of interfaces.

原则 5.构建具有有效模块化的软件。关注点分离(原则 1)建立了软件哲学。模块化提供了实现这一理念的机制。任何复杂的系统都可以分为模块(组件),但良好的软件工程实践要求更多。模块化必须有效。也就是说,每个模块应该专门关注系统的一个受良好约束的方面。此外,模块应该以相对简单的方式与其他模块、数据源和其他环境方面互连。

Principle 5. Build software that exhibits effective modularity. Separation of concerns (Principle 1) establishes a philosophy for software. Modularity provides a mechanism for realizing the philosophy. Any complex system can be divided into modules (components), but good software engineering practice demands more. Modularity must be effective. That is, each module should focus exclusively on one well-constrained aspect of the system. Additionally, modules should be interconnected in a relatively simple manner to other modules, to data sources, and to other environmental aspects.

原则 6.寻找模式。软件工程师使用模式作为对他们过去遇到的问题进行编目和重用解决方案的一种手段。通过允许复杂系统中的组件独立发展,这些设计模式的使用可以应用于更广泛的系统工程和系统集成问题。模式将在第 14 章中进一步讨论。

Principle 6. Look for patterns. Software engineers use patterns as a means of cataloging and reusing solutions to problems they have encountered in the past. The use of these design patterns can be applied to wider systems engineering and systems integration problems, by allowing components in complex systems to evolve independently. Patterns will be discussed further in Chapter 14.

原则 7.如果可能,从几个不同的角度描述问题及其解决方案。当从不同角度审视问题及其解决方案时,更有可能获得更深入的洞察,并发现错误和遗漏。统一建模语言 (UML) 提供了一种从多个角度描述问题解决方案的方法,如附录 1中所述。第88页

Principle 7. When possible, represent the problem and its solution from several different perspectives. When a problem and its solution are examined from different perspectives, it is more likely that greater insight will be achieved and that errors and omissions will be uncovered. The unified modeling language (UML) provides a means of describing a problem solution from multiple viewpoints, as described in Appendix 1.Page 88

原则 8.请记住,软件将由专人维护。从长远来看,软件将随着缺陷的发现而得到纠正,随着环境的变化而进行调整,并随着利益相关者要求更多的功能而得到增强。如果在整个软件过程中应用可靠的软件工程实践,则可以促进这些维护活动。

Principle 8. Remember that someone will maintain the software. Over the long term, software will be corrected as defects are uncovered, adapted as its environment changes, and enhanced as stakeholders request more capabilities. These maintenance activities can be facilitated if solid software engineering practice is applied throughout the software process.

这些原则并不是构建高质量软件所需的全部内容,但它们确实为本书中讨论的每种软件工程方法奠定了基础。

These principles are not all you’ll need to build high-quality software, but they do establish a foundation for every software engineering method discussed in this book.

6.2 指导每个框架活动的原则

6.2 Principles That Guide Each Framework Activity

在接下来的部分中,我们将考虑对定义为软件过程一部分的每个通用框架活动的成功有重大影响的原则。在许多情况下,针对每个框架活动讨论的原则是第 6.1 节中提出的原则的细化。它们只是在较低抽象层次上阐述的核心原则。

In the sections that follow, we consider principles that have a strong bearing on the success of each generic framework activity defined as part of the software process. In many cases, the principles that are discussed for each of the framework activities are a refinement of the principles presented in Section 6.1. They are simply core principles stated at a lower level of abstraction.

6.2.1 通讯原理

6.2.1 Communication Principles

在分析、建模或指定客户需求之前,必须通过沟通活动收集这些需求。客户遇到的问题可能需要基于计算机的解决方案。您回应客户的帮助请求。沟通已经开始。但从沟通到理解的道路往往充满坎坷。

Before customer requirements can be analyzed, modeled, or specified, they must be gathered through the communication activity. A customer has a problem that may be amenable to a computer-based solution. You respond to the customer’s request for help. Communication has begun. But the road from communication to understanding is often full of potholes.

有效的沟通(技术同行之间、与客户和其他利益相关者之间以及与项目经理之间)是您将面临的最具挑战性的活动之一。沟通的方式有很多种,但重要的是要认识到并非所有方式的丰富性或有效性都是相同的(图 6.2)。在此背景下,我们讨论适用于客户沟通的沟通原则。然而,许多原则同样适用于软件项目中发生的所有形式的通信。

Effective communication (among technical peers, with the customer and other stakeholders, and with project managers) is among the most challenging activities that you will confront. There are many ways to communicate, but it’s important to recognize that not all are equal in richness or effectiveness (Figure 6.2). In this context, we discuss communication principles as they apply to customer communication. However, many of the principles apply equally to all forms of communication that occur within a software project.

图6.2 通信方式的有效性

Figure 6.2 Effectiveness of communication modes

第89页原则 1.倾听。在沟通之前,一定要了解对方的观点,了解一下他或她的需求,然后倾听。尝试专注于说话者的话,而不是制定你对这些话的回应。如果有不清楚的地方,请要求澄清,并避免不断打扰。当别人说话时,切勿在言语或行为上引起争议(例如,翻白眼或摇头)。

Page 89Principle 1. Listen. Before communicating, be sure you understand the point of view of the other party, know a bit about his or her needs, and then listen. Try to focus on the speaker’s words, rather than formulating your response to those words. Ask for clarification if something is unclear, and avoid constant interruptions. Never become contentious in your words or actions (e.g., rolling your eyes or shaking your head) as a person is talking.

原则 2.沟通前做好准备。在与他人会面之前,花时间了解问题。如有必要,请进行一些研究以了解业务领域术语。如果您负责主持会议,请在会议前准备好议程。

Principle 2. Prepare before you communicate. Spend the time to understand the problem before you meet with others. If necessary, do some research to understand business domain jargon. If you have responsibility for conducting a meeting, prepare an agenda in advance of the meeting.

原则 3.应该有人为活动提供便利。每次沟通会议都应该有一位领导者(协调人)来保持对话朝着富有成效的方向发展,(2) 调解确实发生的任何冲突,(3) 确保遵循其他原则。

Principle 3. Someone should facilitate the activity. Every communication meeting should have a leader (a facilitator) to keep the conversation moving in a productive direction, (2) to mediate any conflict that does occur, and (3) to ensure that other principles are followed.

原则4.面对面的沟通是最好的。然而,当存在相关信息的其他表示形式时,这种通信通常效果更好。例如,参与者可以创建绘图或“稻草人”文档作为讨论的焦点。

Principle 4. Face-to-face communication is best. However, this communication usually works better when some other representation of the relevant information is present. For example, a participant may create a drawing or a “strawman” document that serves as a focus for discussion.

原则 5.做笔记并记录决定。事情总会有陷入裂缝的时候。参与沟通的人应该充当“记录员”,写下所有重要的观点和决定。

Principle 5. Take notes and document decisions. Things have a way of falling into the cracks. Someone participating in the communication should serve as a “recorder” and write down all important points and decisions.

原则 6.努力协作。当团队成员的集体知识被用来描述产品或系统功能或特性时,就会发生协作和共识。每次小型协作都有助于在团队成员之间建立信任并为团队创建共同目标。

Principle 6. Strive for collaboration. Collaboration and consensus occur when the collective knowledge of members of the team is used to describe product or system functions or features. Each small collaboration serves to build trust among team members and creates a common goal for the team.

第90页原则 7.保持专注;模块化你的讨论。参与交流的人越多,讨论从一个主题跳到下一个主题的可能性就越大。主持人应该保持对话模块化,仅在解决一个主题后才留下一个主题(但是,请参阅原则 9)。

Page 90Principle 7. Stay focused; modularize your discussion. The more people are involved in any communication, the more likely that discussion will bounce from one topic to the next. The facilitator should keep the conversation modular, leaving one topic only after it has been resolved (however, see Principle 9).

原则 8.如果有不清楚的地方,画一张图。口头交流只能到此为止。当文字无法起到作用时,草图或绘图通常可以提供清晰的信息。

Principle 8. If something is unclear, draw a picture. Verbal communication goes only so far. A sketch or drawing can often provide clarity when words fail to do the job.

原则 9. (a) 一旦你同意某件事,就继续前进。(b) 如果您不能同意某件事,请继续前进。(c) 如果某个特性或功能不清楚并且现在无法澄清,请继续。与任何软件工程活动一样,沟通也需要时间。参与人员不应无休止地迭代,而应认识到许多主题需要讨论(参见原则 2),并且“继续前进”有时是实现沟通敏捷性的最佳方式。

Principle 9. (a) Once you agree to something, move on. (b) If you can’t agree to something, move on. (c) If a feature or function is unclear and cannot be clarified right now, move on. Communication, like any software engineering activity, takes time. Rather than iterating endlessly, the people who participate should recognize that many topics require discussion (see Principle 2) and that “moving on” is sometimes the best way to achieve communication agility.

原则 10.谈判不是竞赛或游戏。当双方都赢时效果最好。在许多情况下,您和其他利益相关者必须协商功能和特性、优先级和交付日期。如果团队合作良好,各方都有共同的目标。尽管如此,谈判仍需要各方做出妥协。

Principle 10. Negotiation is not a contest or a game. It works best when both parties win. There are many instances in which you and other stakeholders must negotiate functions and features, priorities, and delivery dates. If the team has collaborated well, all parties have a common goal. Still, negotiation will demand compromise from all parties.

第91页

Page 91

6.2.2 规划原则

6.2.2 Planning Principles

规划活动包含一组管理和技术实践,使软件团队能够在实现其战略目标和战术目标时定义路线图。

The planning activity encompasses a set of management and technical practices that enable the software team to define a road map as it travels toward its strategic goal and tactical objectives.

无论我们如何努力,都无法准确预测软件项目将如何发展。没有简单的方法可以确定将遇到哪些不可预见的技术问题、哪些重要信息将在项目后期才被发现、将发生哪些误解或哪些业务问题将发生变化。然而,一个优秀的软件团队必须规划其方法。规划通常是迭代的(图 6.3)。

Try as we might, it’s impossible to predict exactly how a software project will evolve. There is no easy way to determine what unforeseen technical problems will be encountered, what important information will remain undiscovered until late in the project, what misunderstandings will occur, or what business issues will change. And yet, a good software team must plan its approach. Often planning is iterative (Figure 6.3).

图6.3迭代 规划

Figure 6.3 Iterative planning

有不同的规划理念。3有些人是“极简主义者”,他们认为改变往往不需要详细的计划。另一些人是“传统主义者”,他们认为该计划提供了有效的路线图,而且细节越多,团队迷失的可能性就越小。

There are different planning philosophies.3 Some people are “minimalists,” arguing that change often obviates the need for a detailed plan. Others are “traditionalists,” arguing that the plan provides an effective road map and the more detail it has, the less likely the team will become lost.

该怎么办?在许多项目中,过度计划既耗时又徒劳(太多事情会改变),但计划不足则会导致混乱。就像生活中的大多数事情一样,规划应该灵活并适度进行,足以为团队提供有用的指导——不多也不少。无论规划的执行多么严格,以下原则始终适用:

What to do? On many projects, overplanning is time consuming and fruitless (too many things change), but underplanning is a recipe for chaos. Like most things in life, planning should be agile and conducted in moderation, enough to provide useful guidance for the team—no more, no less. Regardless of the rigor with which planning is conducted, the following principles always apply:

原则 1.了解项目的范围。如果您不知道要去哪里,就不可能使用路线图。范围为软件团队提供了目的地。

Principle 1. Understand the scope of the project. It’s impossible to use a road map if you don’t know where you’re going. Scope provides the software team with a destination.

原则 2.让利益相关者参与规划活动。利益相关者定义优先级并建立项目限制。为了适应这些现实,软件工程师必须经常协商交付顺序、时间表和其他与项目相关的问题。

Principle 2. Involve stakeholders in the planning activity. Stakeholders define priorities and establish project constraints. To accommodate these realities, software engineers must often negotiate order of delivery, time lines, and other project-related issues.

第92页原则 3.认识到规划是迭代的。项目计划从来都不是一成不变的。随着工作的开始,情况很可能会发生变化。该计划将需要调整。迭代增量过程模型包括在交付每个软件增量后根据从用户收到的反馈修改计划的时间。

Page 92Principle 3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it is very likely that things will change. The plan will need to be adjusted. Iterative, incremental process models include time for revising plans after the delivery of each software increment based on feedback received from users.

原则 4.根据您所知道的进行估计。估算的目的是根据团队当前对待完成工作的理解,提供工作量、成本和任务持续时间的指示。如果信息模糊或不可靠,估计也同样不可靠。

Principle 4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done. If information is vague or unreliable, estimates will be equally unreliable.

原则 5.在制定计划时考虑风险。如果您已识别出具有高影响力和高概率的风险,则有必要制定应急计划。应调整项目计划(包括进度表)以适应其中一种或多种风险发生的可能性。

Principle 5. Consider risk as you define the plan. If you have identified risks that have high impact and high probability, contingency planning is necessary. The project plan (including the schedule) should be adjusted to accommodate the likelihood that one or more of these risks will occur.

原则 6.现实一点。人们并不是每天都百分百地工作。改变将会发生。即使是最好的软件工程师也会犯错误。在制定项目计划时应考虑这些和其他现实情况。

Principle 6. Be realistic. People don’t work 100 percent of every day. Changes will occur. Even the best software engineers make mistakes. These and other realities should be considered as a project plan is established.

原则 7.在定义计划时调整粒度。术语“粒度”是指表示或执行规划的某些要素的细节。高粒度计划提供了在相对较短的时间增量内计划的重要工作任务细节(以便经常进行跟踪和控制)。低粒度计划提供了在较长时间内计划的更广泛的工作任务。一般来说,随着项目时间线远离当前日期,粒度从高到低变化。几个月内不会发生的活动不需要高粒度(可能会发生太多变化)。

Principle 7. Adjust granularity as you define the plan. The term granularity refers to the detail with which some element of planning is represented or conducted. A high-granularity plan provides significant work task detail that is planned over relatively short time increments (so that tracking and control occur frequently). A low-granularity plan provides broader work tasks that are planned over longer time periods. In general, granularity moves from high to low as the project time line moves away from the current date. Activities that won’t occur for many months do not require high granularity (too much can change).

原则 8.定义您打算如何确保质量。该计划应确定软件团队打算如何确保质量。如果要进行技术审查4,则应安排时间。如果在施工期间使用结对编程(第3章),则应在计划中明确定义。

Principle 8. Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality. If technical reviews4 are to be conducted, they should be scheduled. If pair programming (Chapter 3) is to be used during construction, it should be explicitly defined within the plan.

原则 9.描述您打算如何适应变化。不受控制的变化甚至可能使最好的计划失效。您应该确定随着软件工程工作的进行如何适应变化。例如,客户可以随时请求更改吗?如果要求更改,团队是否有义务立即实施?如何评估变革的影响和成本?

Principle 9. Describe how you intend to accommodate change. Uncontrolled change can obviate even the best planning. You should identify how changes are to be accommodated as software engineering work proceeds. For example, can the customer request a change at any time? If a change is requested, is the team obliged to implement it immediately? How is the impact and cost of the change assessed?

原则 10.经常跟踪计划,并根据需要进行调整。软件项目一天比一天落后。因此,每天跟踪进度、查找计划工作与实际工作不符的问题领域和情况是有意义的。当遇到延误时,计划也会相应调整。

Principle 10. Track the plan frequently, and make adjustments as required. Software projects fall behind schedule one day at a time. Therefore, it makes sense to track progress daily, looking for problem areas and situations in which scheduled work does not conform to actual work conducted. When slippage is encountered, the plan is adjusted accordingly.

为了达到最有效的效果,软件团队中的每个人都应该参与规划活动。只有这样,团队成员才会“签署”该计划。

To be most effective, everyone on the software team should participate in the planning activity. Only then will team members “sign up” to the plan.

6.2.3 建模原理

6.2.3 Modeling Principles

我们创建模型是为了更好地理解要构建的实际实体。当实体是物理事物(例如建筑物、飞机、机器)时,我们可以构建形式和形状相同但比例较小的三维(3D)模型。然而,当要构建的实体是软件时,我们的模型必须采用不同的形式。它必须能够表示软件转换的信息、实现转换的架构和功能、用户所需的功能以及转换发生时系统的行为。模型必须在不同的抽象级别上实现这些目标——首先从客户的角度描述软件,然后在更技术的级别上表示软件。图 6.4显示了如何在敏捷软件设计中使用建模。第93页

We create models to gain a better understanding of the actual entity to be built. When the entity is a physical thing (e.g., a building, a plane, a machine), we can build a three-dimensional (3D) model that is identical in form and shape but smaller in scale. However, when the entity to be built is software, our model must take a different form. It must be capable of representing the information that software transforms, the architecture and functions that enable the transformation to occur, the features that users desire, and the behavior of the system as the transformation is taking place. Models must accomplish these objectives at different levels of abstraction—first depicting the software from the customer’s viewpoint and later representing the software at a more technical level. Figure 6.4 shows how modeling may be used in agile software design.Page 93

6.4软件建模的 作用

Figure 6.4 Role of software modeling

在软件工程工作中,可以创建两类模型:需求模型和设计模型。需求模型(也称为分析模型)通过在三个不同域中描述软件来表示客户需求:信息域、功能域和行为域(第 8 章)。设计模型代表了帮助从业者有效构建软件的特征:架构、用户界面和组件级细节(第9 章第 12章)。

In software engineering work, two classes of models can be created: requirements models and design models. Requirements models (also called analysis models) represent customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain (Chapter 8). Design models represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail (Chapters 9 through 12).

在他们关于敏捷建模的书中,Scott Ambler 和 Ron Jeffries [Amb02] 定义了一组建模原则5,这些原则适用于那些使用敏捷过程模型(第 3 章)的人,但也适用于执行建模操作和任务的所有软件工程师:

In their book on agile modeling, Scott Ambler and Ron Jeffries [Amb02] define a set of modeling principles5 that are intended for those who use an agile process model (Chapter 3) but are appropriate for all software engineers who perform modeling action and tasks:

原则 1.软件团队的主要目标是构建软件,而不是创建模型。敏捷性意味着在尽可能快的时间内将软件交付给客户。实现这一目标的模型值得创建,但应该避免减慢进程或提供很少新见解的模型。

Principle 1. The primary goal of the software team is to build software, not create models. Agility means getting software to the customer in the fastest possible time. Models that make this happen are worth creating, but models that slow the process down or provide little new insight should be avoided.

第94页原则 2.轻装上阵——不要创建超出您需要的模型。创建的每个模型都必须在发生变化时保持最新。更重要的是,每个新模型都需要花费时间,否则这些时间可能会花在构建(编码和测试)上。因此,仅创建那些能够更轻松、更快速地构建软件的模型。

Page 94Principle 2. Travel light—don’t create more models than you need. Every model that is created must be kept up to date as changes occur. More importantly, every new model takes time that might otherwise be spent on construction (coding and testing). Therefore, create only those models that make it easier and faster to construct the software.

原则 3.努力生成描述问题或软件的最简单模型。不要过度构建软件 [Amb02]。通过保持模型简单,最终的软件也会很简单。结果是软件更容易集成、更容易测试、更容易维护(更改)。此外,简单的模型更容易让软件团队的成员理解和批评,从而产生持续的反馈形式,从而优化最终结果。

Principle 3. Strive to produce the simplest model that will describe the problem or the software. Don’t overbuild the software [Amb02]. By keeping models simple, the resultant software will also be simple. The result is software that is easier to integrate, easier to test, and easier to maintain (to change). In addition, simple models are easier for members of the software team to understand and critique, resulting in an ongoing form of feedback that optimizes the end result.

原则 4.以易于改变的方式构建模型。假设你的模型会改变,但在做出这个假设时不要马虎。这种态度的问题在于,您可能无法创建一个相当完整的需求模型,这意味着您将创建一个总是会错过重要功能和特性的设计(设计模型)。

Principle 4. Build models in a way that makes them amenable to change. Assume that your models will change, but in making this assumption don’t get sloppy. The problem with this attitude is that you may not create a reasonably complete requirements model, which means you’ll create a design (design model) that will invariably miss important functions and features.

原则 5.能够为创建的每个模型阐明明确的目的。每次创建模型时,问问自己为什么要这样做。如果您无法为模型的存在提供可靠的理由,请不要在其上花费时间。

Principle 5. Be able to state an explicit purpose for each model that is created. Every time you create a model, ask yourself why you’re doing so. If you can’t provide solid justification for the existence of the model, don’t spend time on it.

原则 6.使您开发的模型适应当前的系统。可能需要根据应用程序调整模型符号或规则;例如,视频游戏应用程序可能需要与汽车自适应巡航控制的实时嵌入式软件不同的建模技术。

Principle 6. Adapt the models you develop to the system at hand. It may be necessary to adapt model notation or rules to the application; for example, a video game application might require a different modeling technique than real-time, embedded software for adaptive cruise control in an automobile.

原则 7.尝试构建有用的模型,但忘记构建完美的模型。在构建需求和设计模型时,软件工程师会达到收益递减点。也就是说,建立一个完整且内部一致的模型所需的努力可能不值得这些属性带来的好处。无休止地迭代以使模型“完美”并不能满足敏捷性的需求。

Principle 7. Try to build useful models, but forget about building perfect models. When building requirements and design models, a software engineer reaches a point of diminishing returns. That is, the effort required to make a model that is complete and internally consistent may not be worth the benefits of these properties. Iterating endlessly to make a model “perfect” does not serve the need for agility.

原则 8.不要对模型的语法变得教条。如果它成功地传达了内容,那么表达就是次要的。尽管软件团队中的每个人都应该在建模期间尝试使用一致的符号,但模型最重要的特征是传达支持下一个软件工程任务的信息。如果模型成功地做到了这一点,则可以原谅不正确的语法。

Principle 8. Don’t become dogmatic about the syntax of the model. If it communicates content successfully, representation is secondary. Although everyone on a software team should try to use consistent notation during modeling, the most important characteristic of the model is to communicate information that enables the next software engineering task. If a model does this successfully, incorrect syntax can be forgiven.

原则 9.如果你的直觉告诉你某个模型不正确,尽管它在纸面上看起来不错,那么你可能有理由担心。如果您是一位经验丰富的软件工程师,请相信您的直觉。软件工作可以教会我们很多教训——其中一些是在潜意识层面上的。如果某件事告诉您某个设计模型注定会失败(即使您无法明确证明),那么您就有理由花额外的时间检查该模型或开发不同的模型。

Principle 9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have reason to be concerned. If you are an experienced software engineer, trust your instincts. Software work teaches many lessons—some of them on a subconscious level. If something tells you that a design model is doomed to fail (even though you can’t prove it explicitly), you have reason to spend additional time examining the model or developing a different one.

原则 10.尽快获得反馈。任何模型的目的都是为了传达信息。它应该独立存在。假设您不会在那里解释模型。每个模型都应该由软件团队的成员进行审查。这些审查的目的是提供反馈,可用于纠正建模错误、改变误解以及添加无意中省略的特性或功能。

Principle 10. Get feedback as soon as you can. The intent of any model is to communicate information. It should stand on its own. Assume that you won’t be there to explain the model. Every model should be reviewed by members of the software team. The intent of these reviews is to provide feedback that can be used to correct modeling mistakes, change misinterpretations, and add features or functions that were inadvertently omitted.

第95页

Page 95

6.2.4 构建原则

6.2.4 Construction Principles

构建活动包括一组编码和测试任务,这些任务导致可交付给客户或最终用户的操作软件。

The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end user.

在现代软件工程工作中,编码可以是:(1)直接创建编程语言源代码,(2)使用中间设计(如要构建的组件的表示)自动生成源代码,或(3)自动生成源代码。使用第四代编程语言(例如,Unreal4 Blueprints)生成可执行代码。6

In modern software engineering work, coding may be: (1) the direct creation of programming language source code, (2) the automatic generation of source code using an intermediate design like representation of the component to be built, or (3) the automatic generation of executable code using a fourth-generation programming language (e.g., Unreal4 Blueprints).6

测试的最初重点是组件级别,通常称为单元测试。其他级别的测试包括 (1)集成测试(在系统构建时进行),(2)验证测试,评估整个系统(或软件增量)是否满足要求,以及 (3)进行的验收测试由客户努力执行所有必需的特性和功能。图 6.5显示了测试和测试用例设计在敏捷流程中的位置。

The initial focus of testing is at the component level, often called unit testing. Other levels of testing include (1) integration testing (conducted as the system is constructed), (2) validation testing that assesses whether requirements have been met for the complete system (or software increment), and (3) acceptance testing that is conducted by the customer in an effort to exercise all required features and functions. Figure 6.5 shows where testing and test case design is placed in agile processes.

图6.5敏捷 流程中的测试

Figure 6.5 Testing in agile processes

第 19 章第 21 章详细讨论了测试。以下一组基本原则和概念适用于编码和测试。

Testing is considered in detail in Chapters 19 through 21. The following set of fundamental principles and concepts are applicable to coding and testing.

第96页编码原则。指导编码任务的原则与编程风格、编程语言和编程方法密切相关。有一些可以遵循的基本原则:

Page 96Coding Principles. The principles that guide the coding task are closely aligned with programming style, programming languages, and programming methods. There are some fundamental principles that might be followed:

准备原则:在编写一行代码之前,请确保:

Preparation Principles: Before you write one line of code, be sure you:

原则 1.了解您要解决的问题。

Principle 1. Understand the problem you’re trying to solve.

原则 2.了解基本的设计原则和概念。

Principle 2. Understand basic design principles and concepts.

原则 3.选择一种能够满足要构建的软件及其运行环境的需求的编程语言。

Principle 3. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate.

原则 4.选择一个能够提供使您的工作更轻松的工具的编程环境。

Principle 4. Select a programming environment that provides tools that will make your work easier.

原则 5.创建一组单元测试,在您编写的组件完成后将应用这些单元测试。

Principle 5. Create a set of unit tests that will be applied once the component you code is completed.

编码原则:当您开始编写代码时,请确保:

Coding Principles: As you begin writing code, be sure you:

原则 6.通过遵循结构化编程 [Boh00] 实践来约束您的算法。

Principle 6. Constrain your algorithms by following structured programming [Boh00] practice.

原则 7.考虑使用结对编程。

Principle 7. Consider the use of pair programming.

原则 8.选择满足设计需求的数据结构。

Principle 8. Select data structures that will meet the needs of the design.

原则 9.了解软件架构并创建与其一致的界面。

Principle 9. Understand the software architecture and create interfaces that are consistent with it.

验证原则:完成第一次编码后,请确保:

Validation Principles: After you’ve completed your first coding pass, be sure you:

原则 10.在适当的时候进行代码排查。

Principle 10. Conduct a code walkthrough when appropriate.

原则 11.执行单元测试并纠正您发现的错误。

Principle 11. Perform unit tests and correct errors you’ve uncovered.

原则 12.重构代码以提高其质量。

Principle 12. Refactor the code to improve its quality.

测试原理。在一本关于软件测试的经典书籍中,Glen Myers [Mye79] 陈述了许多可以很好地实现测试目标的规则:

Testing Principles. In a classic book on software testing, Glen Myers [Mye79] states a number of rules that can serve well as testing objectives:

1.测试是为了发现错误而执行程序的过程。

1. Testing is a process of executing a program with the intent of finding an error.

2.一个好的测试用例是很有可能发现尚未发现的错误的测试用例。

2. A good test case is one that has a high probability of finding an as-yet-undiscovered error.

3.成功的测试是发现尚未发现的错误的测试。

3. A successful test is one that uncovers an as-yet-undiscovered error.

这些目标意味着一些软件开发人员的观点发生了巨大变化。它们与普遍持有的观点相反,即成功的测试是没有发现错误的测试。您的目标是设计测试,系统地发现不同类别的错误,并以最少的时间和精力完成此任务。

These objectives imply a dramatic change in viewpoint for some software developers. They move counter to the commonly held view that a successful test is one in which no errors are found. Your objective is to design tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort.

第97页作为次要好处,测试表明软件功能似乎按照规范运行,并且行为和性能要求似乎已得到满足。此外,测试时收集的数据可以很好地表明软件可靠性和软件质量。测试不能表明不存在错误和缺陷;它只能表明存在软件错误和缺陷(图 6.6)。在进行测试时,记住这一(相当悲观的)声明很重要。

Page 97As a secondary benefit, testing demonstrates that software functions appear to be working according to specification and that behavioral and performance requirements appear to have been met. In addition, the data collected as testing is conducted provide a good indication of software reliability and some indication of software quality. Testing cannot show the absence of errors and defects; it can show only that software errors and defects are present (Figure 6.6). It is important to keep this (rather gloomy) statement in mind as testing is being conducted.

图6.6测试 永远不会完成

Figure 6.6 Testing is never complete

Davis [Dav95b] 建议了一套测试原则7,这些原则已在本书中进行了改编。此外,Everett 和 Meyer [Eve09] 提出了额外的原则:

Davis [Dav95b] suggests a set of testing principles7 that have been adapted for use in this book. In addition, Everett and Meyer [Eve09] suggest additional principles:

原则 1.所有测试均应可追溯至客户要求。8软件测试的目的是发现错误。由此可见,最严重的缺陷(从客户的角度来看)是导致程序无法满足其要求的缺陷。

Principle 1. All tests should be traceable to customer requirements.8 The objective of software testing is to uncover errors. It follows that the most severe defects (from the customer’s point of view) are those that cause the program to fail to meet its requirements.

原则 2.应该在测试开始之前就计划好测试。需求模型完成后就可以开始测试计划(第 19 章)。设计模型固化后,就可以开始详细定义测试用例。因此,可以在生成任何代码之前规划和设计所有测试。

Principle 2. Tests should be planned long before testing begins. Test planning (Chapter 19) can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated.

原则 3.帕累托原则适用于软件测试。在这种情况下,帕累托原则意味着测试期间发现的所有错误中 80% 可能可以追溯到所有程序组件的 20%。当然,问题是隔离这些可疑组件并彻底测试它们。第98页

Principle 3. The Pareto principle applies to software testing. In this context, the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and to thoroughly test them.Page 98

原则 4.测试应该从“小规模”开始,然后逐步进行“大规模”测试。计划和执行的第一个测试通常集中于单个组件。随着测试的进行,重点转移到寻找集成组件集群中的错误,并最终寻找整个系统中的错误。

Principle 4. Testing should begin “in the small” and progress toward testing “in the large.” The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts to looking for errors in integrated clusters of components and ultimately in the entire system.

原则 5.不可能进行详尽的测试。即使是中等大小的程序,路径排列的数量也非常大。因此,在测试期间不可能执行所有路径组合。然而,可以充分覆盖程序逻辑并确保组件级设计中的所有条件都已得到执行。

Principle 5. Exhaustive testing is not possible. The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised.

原则 6.对系统中的每个模块应用与其预期故障密度相称的测试工作。这些通常是最新的模块或开发人员最不了解的模块。

Principle 6. Apply to each module in the system a testing effort commensurate with its expected fault density. These are often the newest modules or the ones that are least understood by the developers.

原则 7.静态测试技术可以产生良好的结果。超过 85% 的软件缺陷源自软件文档(需求、规范、代码演练和用户手册)[Jon91]。测试系统文档可能有价值。

Principle 7. Static testing techniques can yield high results. More than 85 percent of software defects originate in the software documentation (requirements, specifications, code walk-throughs, and user manuals) [Jon91]. There may be value in testing the system documentation.

原则 8.跟踪缺陷并寻找测试发现的缺陷的模式。发现的缺陷总数是软件质量的良好指标。发现的缺陷类型可以很好地衡量软件稳定性。随着时间的推移发现的缺陷模式可以预测预期缺陷的数量。

Principle 8. Track defects and look for patterns in defects uncovered by testing. The total defects uncovered is a good indicator of software quality. The types of defects uncovered can be a good measure of software stability. Patterns of defects found over time can forecast numbers of expected defects.

原则 9.包括证明软件行为正确的测试用例。在维护或调整软件组件时,意外的交互会导致其他组件出现意想不到的副作用。准备一组回归测试用例(第 19 章)来检查软件产品更改后的系统行为非常重要。

Principle 9. Include test cases that demonstrate software is behaving correctly. As software components are being maintained or adapted, unexpected interactions cause unintended side effects in other components. It is important to have a set of regression test cases (Chapter 19) ready to check system behavior after changes are made to a software product.

6.2.5 部署原则

6.2.5 Deployment Principles

正如我们在本书第一部分中指出的,部署活动包含三个操作:交付、支持和反馈。由于现代软件过程模型本质上是渐进式或渐进式的,因此部署不是一次,而是随着软件走向完成而发生多次。每个交付周期都为客户和最终用户提供可操作的软件增量,以提供可用的功能和特性。每个支持周期都为迄今为止所有部署周期中引入的所有功能和特性提供文档和人工协助。每个反馈周期都为软件团队提供重要的指导,从而导致对下一个增量所采用的功能、特性和方法进行修改。典型的部署操作如图 6.7所示。

As we noted in Part One of this book, the deployment activity encompasses three actions: delivery, support, and feedback. Because modern software process models are evolutionary or incremental in nature, deployment happens not once, but several times as software moves toward completion. Each delivery cycle provides the customer and end users with an operational software increment that provides usable functions and features. Each support cycle provides documentation and human assistance for all functions and features introduced during all deployment cycles to date. Each feedback cycle provides the software team with important guidance that results in modifications to the functions, features, and approach taken for the next increment. Typical deployment actions are illustrated in Figure 6.7.

图6.7部署 动作

Figure 6.7 Deployment actions

软件增量的交付对于任何软件项目来说都是一个重要的里程碑。当团队准备交付增量时,应遵循一些关键原则:

The delivery of a software increment represents an important milestone for any software project. Some key principles should be followed as the team prepares to deliver an increment:

原则 1.必须管理客户对软件的期望。很多时候,客户的期望超出了团队承诺的交付范围,并且立即感到失望。这会导致反馈无效并破坏团队士气。Naomi Karten [Kar94] 在她关于管理期望的书中指出:“管理期望的起点是更加认真地对待沟通的内容和方式。” 她建议软件工程师在向客户发送相互冲突的消息时必须小心(例如,承诺的内容超出了您在规定时间内合理交付的范围,或者对一个软件增量的交付量超出了您的承诺量,而对下一个软件增量的交付量又低于您的承诺量)。第99页

Principle 1. Customer expectations for the software must be managed. Too often, the customer expects more than the team has promised to deliver, and disappointment occurs immediately. This results in feedback that is not productive and ruins team morale. In her book on managing expectations, Naomi Karten [Kar94] states: “The starting point for managing expectations is to become more conscientious about what you communicate and how.” She suggests that a software engineer must be careful about sending the customer conflicting messages (e.g., promising more than you can reasonably deliver in the time period provided or delivering more than you promise for one software increment and then less than promised for the next).Page 99

原则 2.完整的交付包应进行组装和测试。所有可执行软件、支持数据文件、支持文档和其他相关信息都应与实际用户一起组装并进行彻底的测试。所有安装脚本和其他操作功能都应在所有可能的计算配置(即硬件、操作系统、外围设备、网络安排)中彻底运用。

Principle 2. A complete delivery package should be assembled and tested. All executable software, support data files, support documents, and other relevant information should be assembled and thoroughly beta-tested with actual users. All installation scripts and other operational features should be thoroughly exercised in all possible computing configurations (i.e., hardware, operating systems, peripheral devices, networking arrangements).

原则 3.在交付软件之前必须建立支持方案。当出现疑问或问题时,最终用户期望得到响应和准确的信息。如果支持是临时的,或者更糟糕的是,不存在,客户将立即感到不满意。应规划支持,准备支持材料,并建立适当的记录保存机制,以便软件团队可以对所请求的支持类型进行分类评估。

Principle 3. A support regimen must be established before the software is delivered. An end user expects responsiveness and accurate information when a question or problem arises. If support is ad hoc, or worse, nonexistent, the customer will become dissatisfied immediately. Support should be planned, support materials should be prepared, and appropriate record-keeping mechanisms should be established so that the software team can conduct a categorical assessment of the kinds of support requested.

原则 4.必须向最终用户提供适当的指导材料。软件团队提供的不仅仅是软件本身。应开发适当的培训辅助工具(如果需要);应提供故障排除指南,并在必要时发布“此软件增量有何不同”描述。9第 100 页

Principle 4. Appropriate instructional materials must be provided to end users. The software team delivers more than the software itself. Appropriate training aids (if required) should be developed; troubleshooting guidelines should be provided, and when necessary, a “what’s different about this software increment” description should be published.9Page 100

原则 5.有缺陷的软件应该先修复,然后再交付。在时间压力下,一些软件组织提供低质量的增量,并警告客户错误“将在下一个版本中修复”。这是个错误。软件行业有一句话:“客户会忘记你晚了几天交付了高质量的产品,但他们永远不会忘记低质量的产品给他们带来的问题。该软件每天都会提醒他们。”

Principle 5. Buggy software should be fixed first, delivered later. Under time pressure, some software organizations deliver low-quality increments with a warning to the customer that bugs “will be fixed in the next release.” This is a mistake. There’s a saying in the software business: “Customers will forget you delivered a high-quality product a few days late, but they will never forget the problems that a low-quality product caused them. The software reminds them every day.”

6.3 总结

6.3 Summary

软件工程实践包括软件工程师在整个软件过程中应用的原则、概念、方法和工具。每个软件工程项目都是不同的。然而,无论项目或产品如何,一组通用原则都适用于每个框架活动的流程和实践。

Software engineering practice encompasses principles, concepts, methods, and tools that software engineers apply throughout the software process. Every software engineering project is different. Yet, a set of generic principles applies to the process and to the practice of each framework activity regardless of the project or the product.

一组核心原则有助于应用有意义的软件过程和执行有效的软件工程方法。在流程层面,核心原则建立了指导软件团队完成软件流程的哲学基础。在实践层面,核心原则建立了一系列价值观和规则,在您分析问题、设计解决方案、实施和测试解决方案以及最终在用户社区中部署软件时充当指南。

A set of core principles helps in the application of a meaningful software process and the execution of effective software engineering methods. At the process level, core principles establish a philosophical foundation that guides a software team as it navigates through the software process. At the practice level, core principles establish a collection of values and rules that serve as a guide as you analyze a problem, design a solution, implement and test the solution, and ultimately deploy the software in the user community.

通信原则侧重于随着开发人员和客户之间对话的进展,需要降低噪音并提高带宽。双方必须合作才能实现最佳沟通。

Communication principles focus on the need to reduce noise and improve bandwidth as the conversation between developer and customer progresses. Both parties must collaborate for the best communication to occur.

规划原则为构建完整系统或产品的最佳地图提供了指导。该计划可以仅针对单个软件增量进行设计,也可以针对整个项目进行定义。无论如何,它必须解决要做什么、谁来做以及工作何时完成。

Planning principles provide guidelines for constructing the best map for the journey to a completed system or product. The plan may be designed solely for a single software increment, or it may be defined for the entire project. Regardless, it must address what will be done, who will do it, and when the work will be completed.

建模原则是用于创建软件表示的方法和符号的基础。建模包括分析和设计,描述逐渐变得更加详细的软件表示。这些模型的目的是巩固对要完成的工作的理解,并为实施软件的人员提供技术指导。

Modeling principles serve as a foundation for the methods and notation that are used to create representations of the software. Modeling encompasses both analysis and design, describing representations of the software that progressively become more detailed. The intent of the models is to solidify understanding of the work to be done and to provide technical guidance to those who will implement the software.

构建包含编码和测试周期,其中生成和测试组件的源代码。编码原则定义了在编写代码之前、创建代码期间以及完成代码之后应该发生的通用操作。尽管测试原则有很​​多,但只有一个占主导地位:测试是为了发现错误而执行程序的过程。

Construction incorporates a coding and testing cycle in which source code for a component is generated and tested. Coding principles define generic actions that should occur before code is written, while it is being created, and after it has been completed. Although there are many testing principles, only one is dominant: Testing is a process of executing a program with the intent of finding an error.

当每个软件增量呈现给客户并包含交付、支持和反馈时,就会进行部署。交付的关键原则考虑管理客户期望并为客户提供适当的软件支持信息。支持需要提前准备。反馈允许客户提出具有商业价值的更改建议,并为开发人员提供下一个迭代软件工程周期的输入。

Deployment occurs as each software increment is presented to the customer and encompasses delivery, support, and feedback. Key principles for delivery consider managing customer expectations and providing the customer with appropriate support information for the software. Support demands advance preparation. Feedback allows the customer to suggest changes that have business value and provide the developer with input for the next iterative software engineering cycle.

第101页

Page 101

问题与思考点

Problems and Points to Ponder

6.1. 由于对质量的关注需要资源和时间,因此是否有可能在保持敏捷的同时仍然保持对质量的关注?

6.1. Because a focus on quality demands resources and time, is it possible to be agile and still maintain a quality focus?

6.2. 在指导流程的八项核心原则(第 6.1.1 节中讨论)中,您认为哪一项最重要?

6.2. Of the eight core principles that guide process (discussed in Section 6.1.1), which do you believe is most important?

6.3. 用你自己的话描述关注点分离的概念。

6.3. Describe the concept of separation of concerns in your own words.

6.4. 为什么需要“继续前进”?

6.4. Why is it necessary to “move on”?

6.5. 对沟通活动中的“谈判”进行一些研究,并准备一套专门针对谈判的指南。

6.5. Do some research on “negotiation” for the communication activity, and prepare a set of guidelines that focus solely on negotiation.

6.6. 为什么模型在软件工程工作中很重要?它们总是必要的吗?你对必要性的回答有限定条件吗?

6.6. Why are models important in software engineering work? Are they always necessary? Are there qualifiers to your answer about necessity?

6.7. 什么是成功的测试?

6.7. What is a successful test?

6.8。为什么反馈对软件团队很重要?

6.8. Why is feedback important to the software team?

1有些作者主张其中一个术语,而排除其他术语。事实上,软件工程是三者兼而有之。

1 Some writers argue for one of these terms to the exclusion of the others. In reality, software engineering is all three.

2第 5 章讨论了有效软件团队的特征。

2 The characteristics of effective software teams were discussed in Chapter 5.

3本书第四部分详细讨论了软件项目规划和管理。

3 A detailed discussion of software project planning and management is presented in Part Four of this book.

4第 16 章讨论了技术审查。

4 Technical reviews are discussed in Chapter 16.

5出于本书的目的,本节中提到的原则已被缩写和重新表述。

5 The principles noted in this section have been abbreviated and rephrased for the purposes of this book.

6 Blueprints是 Epic Games 创建的可视化脚本工具 (https://docs.unrealengine.com/latest/INT/Engine/Blueprints/)。

6 Blueprints is a visual scripting tool created by Epic Games (https://docs.unrealengine.com/latest/INT/Engine/Blueprints/).

7此处仅记录了戴维斯测试原则的一小部分。有关更多信息,请参阅 [Dav95b]。

7 Only a small subset of Davis’s testing principles are noted here. For more information, see [Dav95b].

8该原则指的是功能测试,即关注需求的测试。结构测试(专注于架构或逻辑细节的测试)可能无法直接解决特定需求。

8 This principle refers to functional tests, that is, tests that focus on requirements. Structural tests (tests that focus on architectural or logical detail) may not address specific requirements directly.

9在沟通活动中,软件团队应确定用户需要什么类型的帮助材料。

9 During the communication activity, the software team should determine what types of help materials users want.

章节

chapter

第102页

Page 102

7了解需求

7 Understanding Requirements

理解问题需求是软件工程师面临的最困难的任务之一。当您第一次思考时,对需求有一个清晰的理解似乎并不难。毕竟,客户不知道需要什么吗?最终用户难道不应该充分了解他们需要的特性和功能吗?令人惊讶的是,在许多情况下,这些问题的答案是否定的。即使客户和最终用户可以明确陈述他们的需求,这些需求也会在整个项目中发生变化。

Understanding problem requirements is among the most difficult tasks facing a software engineer. When you first think about it, developing a clear understanding of the requirements doesn’t seem that hard. After all, doesn’t the customer know what is required? Shouldn’t the end users have a good understanding of the features and functions that they need? Surprisingly, in many instances, the answer to these questions is no. And even if customers and end users can state their needs explicitly, those needs will change throughout the project.

第103页在 Ralph Young [You01] 一本关于有效需求实践的书的前言中,我们中的一个人 [RSP] 写道:

Page 103In the forward to a book by Ralph Young [You01] on effective requirements practices, one of us [RSP] wrote:

  1. 这是你最糟糕的噩梦。一位顾客走进你的办公室,坐下来,直视你的眼睛,然后说:“我知道你认为你理解我所说的,但你不明白的是我所说的并不是我的意思。” 这种情况总是发生在项目的后期,在做出最后期限承诺之后,声誉受到威胁,并且危及大量资金。

  2. It’s your worst nightmare. A customer walks into your office, sits down, looks you straight in the eye, and says, “I know you think you understand what I said, but what you don’t understand is what I said is not what I meant.” Invariably, this happens late in the project, after deadline commitments have been made, reputations are on the line, and serious money is at stake.

  3. 我们所有在系统和软件行业工作了几年多的人都经历过这个噩梦,然而,我们中很少有人学会让它消失。当我们试图征求客户的要求时,我们会遇到困难。我们很难理解我们确实获得的信息。我们经常以杂乱无章的方式记录需求,而且我们花在验证记录内容上的时间太少。我们让变化来控制我们,而不是建立机制来控制变化。简而言之,我们未能为系统或软件建立坚实的基础。这些问题中的每一个都具有挑战性。当它们结合在一起时,即使对于最有经验的管理者和从业者来说,前景也会令人望而生畏。但解决方案确实存在。

  4. All of us who have worked in the systems and software business for more than a few years have lived this nightmare, and yet, few of us have learned to make it go away. We struggle when we try to elicit requirements from our customers. We have trouble understanding the information that we do acquire. We often record requirements in a disorganized manner, and we spend far too little time verifying what we do record. We allow change to control us, rather than establishing mechanisms to control change. In short, we fail to establish a solid foundation for the system or software. Each of these problems is challenging. When they are combined, the outlook is daunting for even the most experienced managers and practitioners. But solutions do exist.

有理由认为,我们将在本章中讨论的技术并不是针对刚刚提到的挑战的真正“解决方案”。但它们确实提供了应对这些挑战的可靠方法。

It’s reasonable to argue that the techniques we’ll discuss in this chapter are not a true “solution” to the challenges just noted. But they do provide a solid approach for addressing these challenges.

7.1 需求工程

7.1 Requirements Engineering

设计和构建计算机软件具有挑战性、创造性,而且非常有趣。事实上,构建软件是如此引人注目,以至于许多软件开发人员都希望在清楚地了解需要什么之前立即投入使用。他们认为,事情会随着构建而变得清晰,项目利益相关者只有在检查软件的早期迭代之后才能理解需求,事情变化如此之快,任何详细理解需求的尝试都是浪费时间,以至于底线是生成一个工作程序,其他一切都是次要的。这些论点之所以有吸引力,是因为它们包含了事实的要素。但每种论点都有缺陷,并可能导致软件项目失败。

Designing and building computer software is challenging, creative, and just plain fun. In fact, building software is so compelling that many software developers want to jump right in before they have a clear understanding of what is needed. They argue that things will become clear as they build, that project stakeholders will be able to understand need only after examining early iterations of the software, that things change so rapidly that any attempt to understand requirements in detail is a waste of time, that the bottom line is producing a working program, and that all else is secondary. What makes these arguments seductive is that they contain elements of truth. But each argument is flawed and can lead to a failed software project.

需求工程是一个术语,指的是有助于理解需求的广泛任务和技术。从软件过程的角度来看,需求工程是一项主要的软件工程活动,它在通信活动期间开始并持续到建模活动。需求工程为设计和构建奠定了坚实的基础。如果没有它,最终的软件很可能无法满足客户的需求。它必须适应流程、项目、产品和工作人员的需求。重要的是要认识到,随着项目团队和利益相关者不断共享有关各自关注点的信息,这些任务中的每一项都是迭代完成的。

Requirements engineering is the term for the broad spectrum of tasks and techniques that lead to an understanding of requirements. From a software process perspective, requirements engineering is a major software engineering action that begins during the communication activity and continues into the modeling activity. Requirements engineering establishes a solid base for design and construction. Without it, the resulting software has a high probability of not meeting customer’s needs. It must be adapted to the needs of the process, the project, the product, and the people doing the work. It is important to realize that each of these tasks is done iteratively as the project team and the stakeholders continue to share information about their respective concerns.

需求工程搭建了设计和施工的桥梁。但这座桥的起源在哪里呢?有人可能会说,它从项目利益相关者(例如,经理、客户和最终用户)开始,其中定义了业务需求,描述了用户场景,描述了功能和特性,并确定了项目约束。其他人可能建议它从更广泛的系统定义开始,其中软件只是更大系统域的​​一个组成部分。但无论起点如何,跨越桥梁的旅程都会将您带入项目的高处,使您能够检查要执行的软件工作的上下文;设计和施工必须满足的具体需求;指导工作完成顺序的优先事项;以及将对最终设计产生深远影响的信息、功能和行为。需求工程包含七个任务,有时界限很模糊:启动、启发、阐述、谈判、规范、验证和管理值得注意的是,其中一些任务是并行发生的,并且所有任务都根据项目的需要进行调整。期望在需求工作期间进行一些设计,并在设计期间进行一些需求工作。第104页

Requirements engineering builds a bridge to design and construction. But where does the bridge originate? One could argue that it begins with the project stakeholders (e.g., managers, customers, and end users), where business needs are defined, user scenarios are described, functions and features are delineated, and project constraints are identified. Others might suggest that it begins with a broader system definition, where software is but one component of the larger system domain. But regardless of the starting point, the journey across the bridge takes you high above the project, allowing you to examine the context of the software work to be performed; the specific needs that design and construction must address; the priorities that guide the order in which work is to be completed; and the information, functions, and behaviors that will have a profound impact on the resulting design. Requirements engineering encompasses seven tasks with sometimes muddy boundaries: inception, elicitation, elaboration, negotiation, specification, validation, and management. It is important to note that some of these tasks occur in parallel and all are adapted to the needs of the project. Expect to do a bit of design during requirements work and a bit of requirements work during design.Page 104

7.1.1 启动

7.1.1 Inception

软件项目如何开始?一般来说,大多数项目都是从已确定的业务需求或发现潜在的新市场或服务时开始的。在项目开始时,您对问题、需要解决方案的人员以及所需解决方案的性质有一个基本的了解。在此任务期间需要建立所有利益相关者和软件团队之间的沟通,以开始有效的协作。

How does a software project get started? In general, most projects begin with an identified business need or when a potential new market or service is discovered. At project inception, you establish a basic understanding of the problem, the people who want a solution, and the nature of the solution that is desired. Communication between all stakeholders and the software team needs to be established during this task to begin an effective collaboration.

7.1.2 启发

7.1.2 Elicitation

这看起来确实很简单——询问客户、用户和其他人系统或产品的目标是什么,要完成什么,系统或产品如何适应业务需求,以及最后,系统如何或产品是日常使用的。但这并不简单——非常困难。

It certainly seems simple enough—ask the customer, the users, and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis. But it isn’t simple—it’s very hard.

启发的一个重要部分是了解业务目标 [Cle10]。目标是系统或产品必须实现长期目标。目标可能涉及功能性或非功能性(例如可靠性、安全性、可用性)问题[Lam09]。

An important part of elicitation is to understand the business goals [Cle10]. A goal is a long-term aim that a system or product must achieve. Goals may deal with either functional or nonfunctional (e.g., reliability, security, usability) concerns [Lam09].

目标通常是向利益相关者解释需求的好方法,一旦建立,就可以用来管理利益相关者之间的冲突。目标应准确指定,并作为需求阐述、验证和确认、冲突管理、谈判、解释和演变的基础。

Goals are often a good way to explain requirements to stakeholders and, once established, can be used to manage conflicts among stakeholders. Goals should be specified precisely and serve as the basis for requirements elaboration, verification and validation, conflict management, negotiation, explanation, and evolution.

您的工作是吸引利益相关者参与并鼓励他们诚实地分享他们的目标。捕获目标后,您可以建立优先级机制并为潜在架构(满足涉众目标)创建设计原理。

Your job is to engage stakeholders and to encourage them to share their goals honestly. Once the goals are captured, you establish a prioritization mechanism and create a design rationale for a potential architecture (that meets stakeholder goals).

敏捷性是需求工程的一个重要方面。启发的目的是将利益相关者的想法顺利且毫不拖延地传递给软件团队。随着产品迭代开发的进行,新的需求很可能会不断出现。

Agility is an important aspect of requirements engineering. The intent of elicitation is to transfer ideas from stakeholders to the software team smoothly and without delay. It is highly likely that new requirements will continue to emerge as iterative product development occurs.

7.1.3 阐述

7.1.3 Elaboration

细化任务的重点是开发一个细化的需求模型,该模型识别软件功能、行为和信息的各个方面(第 8 章)。细化是通过在启发过程中获得的用户场景的创建和细化来驱动的。这些场景描述了最终用户(和其他参与者)如何与系统交互。每个用户场景都被解析以提取分析类——最终用户可见的业务领域实体。定义了每个分析类的属性,并标识了每个类所需的服务。确定了类之间的关系和协作。详细阐述是一件好事,但你需要知道何时停止。关键是以某种方式描述问题,为设计奠定坚实的基础,然后继续前进。不要沉迷于不必要的细节。第105页

The elaboration task focuses on developing a refined requirements model that identifies various aspects of software function, behavior, and information (Chapter 8). Elaboration is driven by the creation and refinement of user scenarios obtained during elicitation. These scenarios describe how the end users (and other actors) will interact with the system. Each user scenario is parsed to extract analysis classes—business domain entities that are visible to the end user. The attributes of each analysis class are defined, and the services that are required by each class are identified. The relationships and collaboration between classes are identified. Elaboration is a good thing, but you need to know when to stop. The key is to describe the problem in a way that establishes a firm base for design and then move on. Do not obsess over unnecessary details.Page 105

7.1.4 谈判

7.1.4 Negotiation

鉴于业务资源有限,客户和用户提出超出其所能实现的要求的情况并不罕见。不同的客户或用户提出相互冲突的要求也是相对常见的,认为他们的版本“对我们的特殊需求至关重要”。

It isn’t unusual for customers and users to ask for more than can be achieved, given limited business resources. It’s also relatively common for different customers or users to propose conflicting requirements, arguing that their version is “essential for our special needs.”

这些矛盾需要通过谈判的过程来调和。要求客户、用户和其他利益相关者对需求进行排序,然后按优先级讨论冲突。有效的谈判不应该有赢家,也没有输家。双方都赢了,因为双方都能接受的“协议”得到了巩固。您应该使用迭代方法来确定需求的优先级、评估其成本和风险并解决内部冲突。通过这种方式,需求被消除、组合和/或修改,以便各方获得某种程度的满意度。

These conflicts need to be reconciled through the process of negotiation. Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in priority. There should be no winner and no loser in an effective negotiation. Both sides win, because a “deal” that both can live with is solidified. You should use an iterative approach that prioritizes requirements, assesses their cost and risk, and addresses internal conflicts. In this way, requirements are eliminated, combined, and/or modified so that each party achieves some measure of satisfaction.

7.1.5 规格

7.1.5 Specification

在基于计算机的系统(和软件)的背景下,术语“规范”对不同的人来说意味着不同的事物。规范可以是书面文档、一组图形模型、正式数学模型、一组使用场景、原型或这些的任意组合。

In the context of computer-based systems (and software), the term specification means different things to different people. A specification can be a written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

一些人建议应该开发一个“标准模板”[Som97]并将其用于规范,认为这会导致以一致且更易于理解的方式呈现需求。然而,有时在开发规范时需要保持灵活性。规范的形式和格式根据要构建的软件的大小和复杂性而变化。对于大型系统,结合自然语言描述和图形模型的书面文档可能是最好的方法。正式软件需求规范文档的模板可以从以下网址下载:https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc。然而,使用场景可能是驻留在易于理解的技术环境中的较小产品或系统所需的全部。

Some suggest that a “standard template” [Som97] should be developed and used for a specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner. However, it is sometimes necessary to remain flexible when a specification is to be developed. The formality and format of a specification varies with the size and the complexity of the software to be built. For large systems, a written document, combining natural language descriptions and graphical models, may be the best approach. A template for a formal software requirements specification document can be downloaded from: https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc. However, usage scenarios may be all that are required for smaller products or systems that reside within well-understood technical environments.

7.1.6 验证

7.1.6 Validation

在验证步骤中对需求工程期间产生的工作产品进行质量评估。需求验证期间的一个关键问题是一致性。使用分析模型确保需求的表述一致。需求验证检查规范以确保所有软件需求都得到明确说明;已发现并纠正不一致、遗漏和错误;工作产品符合为过程、项目和产品制定的标准。

The work products produced during requirements engineering are assessed for quality during a validation step. A key concern during requirements validation is consistency. Use the analysis model to ensure that requirements have been consistently stated. Requirements validation examines the specification to ensure that all software requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product.

主要的需求验证机制是技术审查第16章)。验证需求的审核团队包括软件工程师、客户、用户和其他利益相关者,他们检查规范以查找内容或解释中的错误、可能需要澄清的领域、信息缺失、不一致(大型产品或系统开发时的主要问题)。工程)、相互冲突的要求或不切实际(无法实现)的要求。第106页

The primary requirements validation mechanism is the technical review (Chapter 16). The review team that validates requirements includes software engineers, customers, users, and other stakeholders who examine the specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies (a major problem when large products or systems are engineered), conflicting requirements, or unrealistic (unachievable) requirements.Page 106

为了说明需求验证过程中出现的一些问题,请考虑两个看似无害的需求:

To illustrate some of the problems that occur during requirements validation, consider two seemingly innocuous requirements:

  • 该软件应该是用户友好的。

  • The software should be user friendly.

  • 未经授权的数据库入侵成功的概率应小于 0.0001。

  • The probability of a successful unauthorized database intrusion should be less than 0.0001.

第一个要求对于开发人员来说过于模糊,无法测试或评估。“用户友好”到底是什么意思?为了验证它,必须以某种方式对其进行量化或限定。

The first requirement is too vague for developers to test or assess. What exactly does “user friendly” mean? To validate it, it must be quantified or qualified in some manner.

第二个要求有一个定量元素(“小于0.0001”),但入侵测试将是困难且耗时的。应用程序是否能保证这种级别的安全性?与安全相关的其他补充要求(例如,密码保护、专门的握手)能否取代所指出的定量要求?

The second requirement has a quantitative element (“less than 0.0001”), but intrusion testing will be difficult and time consuming. Is this level of security even warranted for the application? Can other complementary requirements associated with security (e.g., password protection, specialized handshaking) replace the quantitative requirement noted?

7.1.7 需求管理

7.1.7 Requirements Management

基于计算机的系统的需求会发生变化,并且改变需求的愿望在系统的整个生命周期中持续存在。需求管理是一组活动,可帮助项目团队在项目进行过程中随时识别、控制和跟踪需求以及需求变更。其中许多活动与第 22 章中讨论的软件配置管理 (SCM) 技术相同。

Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of the system. Requirements management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds. Many of these activities are identical to the software configuration management (SCM) techniques discussed in Chapter 22.

第107页

Page 107

7.2 建立基础

7.2 Establishing the Groundwork

在理想的环境中,利益相关者和软件工程师在同一个团队中一起工作。在这种情况下,需求工程只是与团队中知名成员的同事进行有意义的对话。但现实往往截然不同。

In an ideal setting, stakeholders and software engineers work together on the same team. In such cases, requirements engineering is simply a matter of conducting meaningful conversations with colleagues who are well-known members of the team. But reality is often quite different.

客户或最终用户可能居住在不同的城市或国家,可能对需求只有一个模糊的想法,可能对要构建的系统有相互矛盾的意见,可能技术知识有限,并且交互时间可能有限与需求工程师。这些事情都不是可取的,但都很常见,而且你常常被迫在这种情况所施加的限制下工作。

Customer(s) or end users may reside in different cities or countries, may have only a vague idea of what is required, may have conflicting opinions about the system to be built, may have limited technical knowledge, and may have limited time to interact with the requirements engineer. None of these things are desirable, but all are common, and you are often forced to work within the constraints imposed by this situation.

在接下来的部分中,我们将讨论为理解软件需求奠定基础所需的步骤,以便以一种能够使其朝着成功的解决方案前进的方式启动项目。

In the sections that follow, we discuss the steps required to establish the groundwork for an understanding of software requirements—to get the project started in a way that will keep it moving forward toward a successful solution.

7.2.1 识别利益相关者

7.2.1 Identifying Stakeholders

Sommerville 和 Sawyer [Som97] 将利益相关者定义为“从正在开发的系统中直接或间接受益的任何人”。我们已经确定了常见的嫌疑人:业务运营经理、产品经理、营销人员、内部和外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师等。每个利益相关者对系统都有不同的看法,在系统成功开发时获得不同的收益,并且在开发工作失败时面临不同的风险。

Sommerville and Sawyer [Som97] define a stakeholder as “anyone who benefits in a direct or indirect way from the system which is being developed.” We have already identified the usual suspects: business operations managers, product managers, marketing people, internal and external customers, end users, consultants, product engineers, software engineers, support and maintenance engineers, and others. Each stakeholder has a different view of the system, achieves different benefits when the system is successfully developed, and is open to different risks if the development effort should fail.

一开始,您应该创建一个人员列表,这些人员将在提出需求时提供意见(第 7.3 节)。随着利益相关者的联系,最初的名单将会不断增加,因为每个利益相关者都会被问到:“你认为我还应该和谁交谈?”

At inception, you should create a list of people who will contribute input as requirements are elicited (Section 7.3). The initial list will grow as stakeholders are contacted because every stakeholder will be asked: “Whom else do you think I should talk to?”

7.2.2 认识多种观点

7.2.2 Recognizing Multiple Viewpoints

由于存在许多不同的利益相关者,系统的需求将从许多不同的角度进行探讨。例如,营销团队对能够激发潜在市场、使新系统易于销售的功能感兴趣。业务经理对可以在预算范围内构建并准备好满足定义的市场窗口的功能集感兴趣。最终用户可能需要他们熟悉且易于学习和使用的功能。软件工程师可能关心非技术利益相关者看不到的功能,但这些功能使基础设施能够支持更多适销对路的功能和特性。支持工程师可能会关注软件的可维护性。

Because many different stakeholders exist, the requirements of the system will be explored from many different points of view. For example, the marketing group is interested in features that will excite the potential market, making the new system easy to sell. Business managers are interested in a feature set that can be built within budget and that will be ready to meet defined market windows. End users may want features that are familiar to them and that are easy to learn and use. Software engineers may be concerned with functions that are invisible to nontechnical stakeholders but that enable an infrastructure that supports more marketable functions and features. Support engineers may focus on the maintainability of the software.

这些支持者(以及其他支持者)中的每一个都将为需求工程过程贡献信息。当收集来自多个观点的信息时,新出现的要求可能不一致或可能相互冲突。您应该对所有利益相关者信息(包括不一致和冲突的需求)进行分类,以便决策者可以为系统选择一组内部一致的需求。

Each of these constituencies (and others) will contribute information to the requirements engineering process. As information from multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict with one another. You should categorize all stakeholder information (including inconsistent and conflicting requirements) in a way that will allow decision makers to choose an internally consistent set of requirements for the system.

有几件事可能会导致很难提出满足用户需求的软件:项目目标不明确,利益相关者的优先级不同,人们有未言明的假设,利益相关者对含义的解释不同,需求的表述方式使得它们难以验证[麦芽酒11]。有效的需求工程的目标是消除或至少减少这些问题。

Several things can make it hard to elicit requirements for software that satisfies its users: project goals are unclear, stakeholders’ priorities differ, people have unspoken assumptions, stakeholders interpret meanings differently, and requirements are stated in a way that makes them difficult to verify [Ale11]. The goal of effective requirements engineering is to eliminate or at least reduce these problems.

第108页

Page 108

7.2.3 致力于协作

7.2.3 Working Toward Collaboration

如果软件项目涉及五个利益相关者,那么您可能对正确的需求集有五种(或更多)不同的意见。在前面的章节中,我们已经注意到,如果要打造一个成功的系统,客户(和其他利益相关者)应该相互协作(避免狭隘的地盘之争)并与软件工程从业者进行协作。但这种合作是如何实现的呢?

If five stakeholders are involved in a software project, you may have five (or more) different opinions about the proper set of requirements. Throughout earlier chapters, we have noted that customers (and other stakeholders) should collaborate among themselves (avoiding petty turf battles) and with software engineering practitioners if a successful system is to result. But how is this collaboration accomplished?

需求工程师的工作是识别共性领域(即所有利益相关者都同意的需求)和冲突或不一致领域(即一个利益相关者期望但与另一利益相关者的需求相冲突的需求)。当然,后一类提出了挑战。

The job of a requirements engineer is to identify areas of commonality (i.e., requirements on which all stakeholders agree) and areas of conflict or inconsistency (i.e., requirements that are desired by one stakeholder but conflict with the needs of another stakeholder). It is, of course, the latter category that presents a challenge.

协作并不一定意味着需求是“由委员会定义的”。在许多情况下,利益相关者通过提供他们对需求的看法来进行协作,但强大的“项目支持者”(例如业务经理或高级技术专家)可能会做出关于哪些需求被削减的最终决定。

Collaboration does not necessarily mean that requirements are “defined by committee.” In many cases, stakeholders collaborate by providing their view of requirements, but a strong “project champion” (e.g., a business manager or a senior technologist) may make the final decision about which requirements make the cut.

7.2.4 提出第一个问题

7.2.4 Asking the First Questions

在项目开始时提出的问题应该是“与上下文无关的”[Gau89]。第一组与上下文无关的问题侧重于客户和其他利益相关者以及总体项目目标和收益。例如,您可能会问:

Questions asked at the inception of the project should be “context free” [Gau89]. The first set of context-free questions focuses on the customer and other stakeholders and the overall project goals and benefits. For example, you might ask:

  • 谁是这项工作请求的背后支持者?

  • Who is behind the request for this work?

  • 谁将使用该解决方案?

  • Who will use the solution?

  • 成功的解决方案会带来什么经济效益?

  • What will be the economic benefit of a successful solution?

  • 您需要的解决方案还有其他来源吗?

  • Is there another source for the solution that you need?

这些问题有助于确定所有对要构建的软件感兴趣的利益相关者。此外,这些问题还确定了成功实施的可衡量的好处以及定制软件开发的可能替代方案。

These questions help to identify all stakeholders who will have interest in the software to be built. In addition, the questions identify the measurable benefit of a successful implementation and possible alternatives to custom software development.

下一组问题可以让您更好地理解问题,并让客户表达她对解决方案的看法:

The next set of questions enables you to gain a better understanding of the problem and allows the customer to voice her perceptions about a solution:

  • 您如何描述成功的解决方案所产生的“良好”输出?

  • How would you characterize “good” output that would be generated by a successful solution?

  • 该解决方案将解决什么问题?

  • What problem(s) will this solution address?

  • 第109页您能否向我展示(或描述)使用该解决方案的业务环境?

  • Page 109Can you show me (or describe) the business environment in which the solution will be used?

  • 特殊的性能问题或限制是否会影响解决方案的实现方式?

  • Will special performance issues or constraints affect the way the solution is approached?

最后一组问题集中于沟通活动本身的有效性。Gause 和 Weinberg [Gau89] 将这些称为“元问题”并提出以下(缩写)列表:

The final set of questions focuses on the effectiveness of the communication activity itself. Gause and Weinberg [Gau89] call these “meta-questions” and propose the following (abbreviated) list:

  • 您是回答这些问题的合适人选吗?您的回答是“官方”的吗?

  • Are you the right person to answer these questions? Are your answers “official”?

  • 我的问题与您遇到的问题相关吗?

  • Are my questions relevant to the problem that you have?

  • 我问的问题太多了吗?

  • Am I asking too many questions?

  • 其他人可以提供更多信息吗?

  • Can anyone else provide additional information?

  • 我还需要问你什么吗?

  • Should I be asking you anything else?

这些问题(以及其他问题)将有助于“打破僵局”并启动对于成功启发至关重要的沟通。但问答 (Q&A) 会议形式并不是一种取得巨大成功的方法。事实上,问答会话应该只在第一次遇到时使用,然后用结合了问题解决、谈判和规范等元素的需求获取格式来代替。7.3 节介绍了这种类型的方法。

These questions (and others) will help to “break the ice” and initiate the communication that is essential to successful elicitation. But a question-and-answer (Q&A) meeting format is not an approach that has been overwhelmingly successful. In fact, the Q&A session should be used for the first encounter only and then replaced by a requirements elicitation format that combines elements of problem solving, negotiation, and specification. An approach of this type is presented in Section 7.3.

7.2.5 非功能性需求

7.2.5 Nonfunctional Requirements

功能性需求(NFR) 可以描述为质量属性、性能属性、安全属性或系统的一般约束。对于利益相关者来说,这些往往不容易阐明。Chung [Chu09] 认为,对软件功能的重视是不平衡的,但如果没有必要的非功能特性,软件可能就没用或不可用。

A nonfunctional requirement (NFR) can be described as a quality attribute, a performance attribute, a security attribute, or a general constraint on a system. These are often not easy for stakeholders to articulate. Chung [Chu09] suggests that there is a lopsided emphasis on functionality of the software, yet the software may not be useful or usable without the necessary nonfunctional characteristics.

可以定义一个两阶段的方法 [Hne11],它可以帮助软件团队和其他利益相关者识别非功能性需求。在第一阶段,为要构建的系统建立一套软件工程指南。其中包括最佳实践指南,还涉及架构风格(第 10 章)和设计模式的使用(第 14 章)。然后开发 NFR 列表(例如,解决可用性、可测试性、安全性或可维护性的要求)。一个简单的表格将 NFR 列为列标签,将软件工程指南列为行标签。关系矩阵将每条准则与所有其他准则进行比较,帮助团队评估每对准则是否互补重叠冲突独立

It is possible to define a two-phase approach [Hne11] that can assist a software team and other stakeholders in identifying nonfunctional requirements. During the first phase, a set of software engineering guidelines is established for the system to be built. These include guidelines for best practice, but also address architectural style (Chapter 10) and the use of design patterns (Chapter 14). A list of NFRs (e.g., requirements that address usability, testability, security, or maintainability) is then developed. A simple table lists NFRs as column labels and software engineering guidelines as row labels. A relationship matrix compares each guideline to all others, helping the team to assess whether each pair of guidelines is complementary, overlapping, conflicting, or independent.

在第二阶段,团队通过使用一组决策规则创建一组同质的非功能性需求来确定每个非功能性需求的优先级,这些决策规则确定要实施哪些指南和要拒绝哪些指南。

In the second phase, the team prioritizes each nonfunctional requirement by creating a homogeneous set of nonfunctional requirements using a set of decision rules that establish which guidelines to implement and which to reject.

7.2.6 可追溯性

7.2.6 Traceability

可追溯性是一个软件工程术语,指的是软件工程工作产品(例如,需求和测试用例)之间记录的链接。可追溯性矩阵允许需求工程师表示需求和其他软件工程工作产品之间的关系。可追溯性矩阵的行使用需求名称来标记,并且列可以使用软件工程工作产品(例如,设计元素或测试用例)的名称来标记。标记矩阵单元以指示两者之间存在链接。第110页

Traceability is a software engineering term that refers to documented links between software engineering work products (e.g., requirements and test cases). A traceability matrix allows a requirements engineer to represent the relationship between requirements and other software engineering work products. Rows of the traceability matrix are labeled using requirement names, and columns can be labeled with the name of a software engineering work product (e.g., a design element or a test case). A matrix cell is marked to indicate the presence of a link between the two.Page 110

可追溯性矩阵可以支持各种工程开发活动。当项目从一个项目阶段转移到另一个项目阶段时,无论使用何种流程模型,它们都可以为开发人员提供连续性。可追溯性矩阵通常可用于确保工程工作产品已考虑到所有要求。

The traceability matrices can support a variety of engineering development activities. They can provide continuity for developers as a project moves from one project phase to another, regardless of the process model being used. Traceability matrices often can be used to ensure the engineering work products have taken all requirements into account.

随着需求数量和工作产品数量的增长,保持可追溯性矩阵最新变得越来越困难。尽管如此,创建一些方法来跟踪产品需求的影响和演变仍然很重要[Got11]。

As the number of requirements and the number of work products grows, it becomes increasingly difficult to keep the traceability matrix up to date. Nonetheless, it is important to create some means for tracking the impact and evolution of the product requirements [Got11].

7.3 需求收集

7.3 Requirements Gathering

需求收集结合了问题解决、阐述、协商和规范等要素。为了鼓励采用协作的、以团队为导向的方法来收集需求,利益相关者共同努力识别问题,提出解决方案的要素,协商不同的方法,并指定一组初步的解决方案需求[Zah90]。

Requirements gathering combines elements of problem solving, elaboration, negotiation, and specification. To encourage a collaborative, team-oriented approach to requirements gathering, stakeholders work together to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements [Zah90].

7.3.1 协作需求收集

7.3.1 Collaborative Requirements Gathering

已经提出了许多不同的协作需求收集方法。每个使用的场景都略有不同,但都在以下基本准则上应用了一些变化:

Many different approaches to collaborative requirements gathering have been proposed. Each makes use of a slightly different scenario, but all apply some variation on the following basic guidelines:

  • 会议(无论是真实的还是虚拟的)由软件工程师和其他利益相关者主持和参加。

  • Meetings (either real or virtual) are conducted and attended by both software engineers and other stakeholders.

  • 制定了准备和参与规则。

  • Rules for preparation and participation are established.

  • 建议制定一个足够正式的议程,以涵盖所有要点,但又足够非正式,以鼓励思想的自由交流。

  • An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas.

  • “协调人”(可以是客户、开发人员或外部人员)控制会议。

  • A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.

  • 使用“定义机制”(可以是工作表、活动挂图、墙贴、电子公告板、聊天室或虚拟论坛)。

  • A “definition mechanism” (can be worksheets, flip charts, or wall stickers or an electronic bulletin board, chat room, or virtual forum) is used.

目标是识别问题、提出解决方案的要素、协商不同的方法并指定一组初步的解决方案要求。

The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements.

在启动期间会生成一页或两页的“产品请求”(第 7.2 节)。选择见面地点、时间和日期;选择一名协调员;并邀请软件团队和其他利益相关者组织的与会者参加。如果一个系统或产品将为许多用户提供服务,请绝对确定需求是从具有代表性的用户群体中引出的。如果只有一个用户定义所有需求,则接受风险很高(意味着可能有其他几个利益相关者不会接受该产品)。产品请求会在会议日期之前分发给所有与会者。

A one- or two-page “product request” is generated during inception (Section 7.2). A meeting place, time, and date are selected; a facilitator is chosen; and attendees from the software team and other stakeholder organizations are invited to participate. If a system or product will serve many users, be absolutely certain that requirements are elicited from a representative cross section of users. If only one user defines all requirements, acceptance risk is high (meaning there may be several other stakeholders who will not accept the product). The product request is distributed to all attendees before the meeting date.

第111页例如,请考虑参与SafeHome项目的营销人员撰写的产品请求的摘录。此人对SafeHome 的家庭安全功能进行了以下叙述:

Page 111As an example, consider an excerpt from a product request written by a marketing person involved in the SafeHome project. This person writes the following narrative about the home security function that is to be part of SafeHome:

我们的研究表明,家庭管理系统市场每年以 40% 的速度增长。我们向市场推出的第一个SafeHome功能应该是家庭安全功能。大多数人都熟悉“警报系统”,因此这很容易推销。我们还可以考虑使用 Alexa 等技术对系统进行语音控制。

Our research indicates that the market for home management systems is growing at a rate of 40 percent per year. The first SafeHome function we bring to market should be the home security function. Most people are familiar with “alarm systems,” so this would be an easy sell. We might also consider using voice control of the system using some technology like Alexa.

家庭安全功能将防止和/或识别各种不良“情况”,例如非法进入、火灾、洪水、一氧化碳水平等。它将使用我们的无线传感器来检测每种情况,可由房主编程,并在检测到情况时自动联系监控机构和房主的手机。

The home security function would protect against and/or recognize a variety of undesirable “situations” such as illegal entry, fire, flooding, carbon monoxide levels, and others. It’ll use our wireless sensors to detect each situation, can be programmed by the homeowner, and will automatically contact a monitoring agency and the owner’s cell phone when a situation is detected.

事实上,其他人会在需求收集会议期间为这种叙述做出贡献,并且可以获得更多的信息。但即使有额外的信息,仍然存在歧义,可能存在遗漏,并且可能出现错误。现在,前面的“功能描述”就足够了。

In reality, others would contribute to this narrative during the requirements gathering meeting and considerably more information would be available. But even with additional information, ambiguity is present, omissions are likely to exist, and errors might occur. For now, the preceding “functional description” will suffice.

在会议前几天审查产品请求时,要求每位与会者列出系统周围环境的对象、系统要生成的其他对象以及系统使用的对象的列表。系统执行其功能。此外,每个与会者都被要求制作另一个操作对象或与对象交互的服务(进程或功能)列表。最后,还制定了约束列表(例如,成本、规模、业务规则)和性能标准(例如,速度、准确性、安全性)。与会者被告知,这些列表预计不会详尽无遗,但预计会反映每个人对系统的看法。

While reviewing the product request in the days before the meeting, each attendee is asked to make a list of objects that are part of the environment that surrounds the system, other objects that are to be produced by the system, and objects that are used by the system to perform its functions. In addition, each attendee is asked to make another list of services (processes or functions) that manipulate or interact with the objects. Finally, lists of constraints (e.g., cost, size, business rules) and performance criteria (e.g., speed, accuracy, security) are also developed. The attendees are informed that the lists are not expected to be exhaustive but are expected to reflect each person’s perception of the system.

SafeHome描述的对象可能包括控制面板、烟雾探测器、门窗传感器、运动探测器、警报、事件(传感器已激活)、显示器、平板电脑、电话号码、电话呼叫等。服务列表可能包括配置系统、设置警报、监视传感器、使用无线路由器拨打电话、对控制面板进行编程以及读取显示内容(请注意,服务作用于对象)。以类似的方式,每个与会者将制定约束列表(例如,系统必须识别传感器何时未运行,必须用户友好,必须直接连接到标准电话线)和性能标准(例如,传感器事件应该是1秒内识别,并应实施事件优先级方案)。

Objects described for SafeHome might include the control panel, smoke detectors, window and door sensors, motion detectors, an alarm, an event (a sensor has been activated), a display, a tablet, telephone numbers, a telephone call, and so on. The list of services might include configuring the system, setting the alarm, monitoring the sensors, dialing the phone using a wireless router, programming the control panel, and reading the display (note that services act on objects). In a similar fashion, each attendee will develop lists of constraints (e.g., the system must recognize when sensors are not operating, must be user friendly, must interface directly to a standard phone line) and performance criteria (e.g., a sensor event should be recognized within 1 second, and an event priority scheme should be implemented).

可以使用大张纸将物品列表固定在房间的墙壁上,使用背胶纸粘贴在墙壁上,或者写在墙板上。或者,这些列表可能已发布在群组论坛或内部网站上,或者在社交网络环境中提出,以供会议之前审阅。理想情况下,每个列出的条目应该能够单独操作,以便可以组合列表、删除条目以及添加条目。在这个阶段,严格禁止批评和辩论。避免因为“成本太高”或“不切实际”而否定客户的想法。这里的想法是协商一份所有人都能接受的清单。为此,您必须保持开放的心态。

The lists of objects can be pinned to the walls of the room using large sheets of paper, stuck to the walls using adhesive-backed sheets, or written on a wall board. Alternatively, the lists may have been posted on a group forum or at an internal website or posed in a social networking environment for review prior to the meeting. Ideally, each listed entry should be capable of being manipulated separately so that lists can be combined, entries can be deleted, and additions can be made. At this stage, critique and debate are strictly prohibited. Avoid the impulse to shoot down a customer’s idea as “too costly” or “impractical.” The idea here is to negotiate a list that is acceptable to all. To do this, you must keep an open mind.

在一个主题区域中呈现各个列表后,小组通过消除冗余条目、添加讨论过程中出现的任何新想法但不删除任何内容来创建一个组合列表。在为所有主题领域创建组合列表后,由主持人协调的讨论随即展开。组合列表被缩短、加长或重新措辞,以正确反映要开发的产品或系统。目标是为要构建的系统制定对象、服务、约束和性能的共识列表。第112页

After individual lists are presented in one topic area, the group creates a combined list by eliminating redundant entries, adding any new ideas that come up during the discussion, but not deleting anything. After you create combined lists for all topic areas, discussion—coordinated by the facilitator—ensues. The combined list is shortened, lengthened, or reworded to properly reflect the product or system to be developed. The objective is to develop a consensus list of objects, services, constraints, and performance for the system to be built.Page 112

在许多情况下,列表中描述的对象或服务需要进一步解释。为了实现这一目标,利益相关者为列表中的条目制定迷你规范,或者通过创建涉及对象或服务的用例(第 7.4 节)。例如, SafeHome对象控制面板的迷你规格可能是:

In many cases, an object or service described on a list will require further explanation. To accomplish this, stakeholders develop mini-specifications for entries on the lists or by creating a use case (Section 7.4) that involves the object or service. For example, the mini-spec for the SafeHome object Control Panel might be:

控制面板为壁挂式单元,尺寸约为 230 × 130 毫米。控制面板具有与传感器和平板电脑的无线连接。用户交互通过包含 12 个按键的键盘进行。75 × 75 mm OLED 彩色显示屏可提供用户反馈。软件提供交互提示、回显等类似功能。

The control panel is a wall-mounted unit that is approximately 230 × 130 mm in size. The control panel has wireless connectivity to sensors and a tablet. User interaction occurs through a keypad containing 12 keys. A 75 × 75 mm OLED color display provides user feedback. Software provides interactive prompts, echo, and similar functions.

迷你规格将提交给所有利益相关者进行讨论。进行了补充、删除和进一步阐述。在某些情况下,迷你规范的开发将发现新的对象、服务、约束或性能要求,这些新的对象、服务、约束或性能要求将添加到原始列表中。在所有讨论过程中,团队可能会提出会议期间无法解决的问题。我们会维护一个问题列表,以便稍后对这些想法采取行动。

The mini-specs are presented to all stakeholders for discussion. Additions, deletions, and further elaboration are made. In some cases, the development of mini-specs will uncover new objects, services, constraints, or performance requirements that will be added to the original lists. During all discussions, the team may raise an issue that cannot be resolved during the meeting. An issues list is maintained so that these ideas will be acted on later.

第113页许多利益相关者关心的问题(例如,准确性、数据可访问性、安全性)是非功能性系统需求的基础(第 7.2 节)。当利益相关者阐明这些问题时,软件工程师必须在要构建的系统的背景下考虑它们。必须回答的问题 [Lag10] 是:

Page 113Many stakeholder concerns (e.g., accuracy, data accessibility, security) are the basis for nonfunctional system requirements (Section 7.2). As stakeholders enunciate these concerns, software engineers must consider them within the context of the system to be built. The questions that must be answered [Lag10] are:

  • 我们可以建立这个系统吗?

  • Can we build the system?

  • 这个开发过程能让我们在市场上击败竞争对手吗?

  • Will this development process allow us to beat our competitors to market?

  • 是否有足够的资源来构建和维护拟议的系统?

  • Do adequate resources exist to build and maintain the proposed system?

  • 系统性能能否满足客户的需求?

  • Will the system performance meet the needs of our customers?

7.3.2 使用场景

7.3.2 Usage Scenarios

随着需求的收集,系统功能和特性的总体愿景开始具体化。然而,除非您了解不同类别的最终用户将如何使用这些功能,否则很难进入技术性更强的软件工程活动。为了实现这一点,开发人员和用户可以创建一组场景来标识要构建的系统的使用线程。这些场景通常称为用例[Jac92],提供了如何使用系统的描述。用例在第 7.4 节中进行了更详细的讨论。

As requirements are gathered, an overall vision of system functions and features begin to materialize. However, it is difficult to move into more technical software engineering activities until you understand how the features will be used by different classes of end users. To accomplish this, developers and users can create a set of scenarios that identify a thread of usage for the system to be constructed. The scenarios, often called use cases [Jac92], provide a description of how the system will be used. Use cases are discussed in greater detail in Section 7.4.

7.3.3 启发工作产品

7.3.3 Elicitation Work Products

需求获取过程中产生的工作产品将根据要构建的系统或产品的规模而有所不同。对于大型系统,工作产品可​​能包括: (1) 需求和可行性的陈述;(2) 系统或产品范围的有限声明;(3) 参与需求获取的客户、用户和其他利益相关者的名单;(4)系统技术环境的描述;(5) 要求列表(最好按功能组织)以及适用于每个要求的领域约束;(6) 一组使用场景,可深入了解系统或产品在不同操作条件下的使用情况。这些工作产品中的每一个都由参与需求获取的所有人员进行审查。

The work products produced during requirements elicitation will vary depending on the size of the system or product to be built. For large systems, the work products may include: (1) a statement of need and feasibility; (2) a bounded statement of scope for the system or product; (3) a list of customers, users, and other stakeholders who participated in requirements elicitation; (4) a description of the system’s technical environment; (5) a list of requirements (preferably organized by function) and the domain constraints that apply to each; and (6) a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. Each of these work products is reviewed by all people who have participated in requirements elicitation.

7.4 开发用例

7.4 Developing Use Cases

用例讲述了一个关于最终用户(扮演几个可能的角色之一)如何在特定情况下与系统交互的程式化故事。故事可以是叙述性文本(用户故事)、任务或交互的概要、基于模板的描述或图表表示。无论其形式如何,用例都是从最终用户的角度描述软件或系统。

A use case tells a stylized story about how an end user (playing one of several possible roles) interacts with the system under a specific set of circumstances. The story may be narrative text (a user story), an outline of tasks or interactions, a template-based description, or a diagrammatic representation. Regardless of its form, a use case depicts the software or system from the end user’s point of view.

编写用例的第一步是定义故事中涉及的一组“参与者”。参与者是在要描述的功能和行为的上下文中使用系统或产品的不同人(或设备)。参与者将代表系统运行时人(或设备)所扮演的角色。更正式地定义,参与者是与系统或产品通信且位于系统本身外部的任何事物。每个参与者在使用该系统时都有一个或多个目标。

The first step in writing a use case is to define the set of “actors” that will be involved in the story. Actors are the different people (or devices) that use the system or product within the context of the function and behavior that is to be described. Actors will represent the roles that people (or devices) play as the system operates. Defined somewhat more formally, an actor is anything that communicates with the system or product and that is external to the system itself. Every actor has one or more goals when using the system.

值得注意的是,参与者和最终用户不一定是同一件事。典型的用户在使用系统时可能扮演多个不同的角色,而参与者代表一类在用例上下文中仅扮演一个角色的外部实体(通常但不总是人)。例如,考虑与允许在虚拟建筑中试验警报传感器配置的程序进行交互的用户。经过仔细审查需求,控制计算机的软件需要四种不同的交互模式(角色):放置模式、测试模式、监控模式和故障排除模式。因此,可以定义四个参与者:编辑者、测试者、监控者和故障排除者。在某些情况下,用户可以扮演所有角色。在其他情况下,不同的人可能扮演每个演员的角色。第115页

It is important to note that an actor and an end user are not necessarily the same thing. A typical user may play several different roles when using a system, whereas an actor represents a class of external entities (often, but not always, people) that play just one role in the context of the use case. As an example, consider a user who interacts with the program that allows experimenting with alarm sensor configuration in a virtual building. After careful review of requirements, the software for the control computer requires four different modes (roles) for interaction: placement mode, testing mode, monitoring mode, and troubleshooting mode. Therefore, four actors can be defined: editor, tester, monitor, and troubleshooter. In some cases, the user can play all the roles. In others, different people may play the role of each actor.Page 115

由于需求启发是一种进化活动,因此并非所有参与者都在第一次迭代期间被识别。随着对系统的了解越来越多,可以在第一次迭代期间识别主要参与者 [Jac92] 和次要参与者。主要参与者相互作用以实现所需的系统功能并从系统中获得预期的利益。他们直接并频繁地使用软件。次要参与者支持系统,以便主要参与者可以完成他们的工作。

Because requirements elicitation is an evolutionary activity, not all actors are identified during the first iteration. It is possible to identify primary actors [Jac92] during the first iteration and secondary actors as more is learned about the system. Primary actors interact to achieve required system function and derive the intended benefit from the system. They work directly and frequently with the software. Secondary actors support the system so that primary actors can do their work.

一旦确定了参与者,就可以开发用例。Jacobson [Jac92] 建议应通过用例回答的问题:

Once actors have been identified, use cases can be developed. Jacobson [Jac92] suggests questions that should be answered by a use case:

  1. 谁是主要演员、次要演员?

  2. Who is the primary actor, the secondary actor(s)?

  3. 演员的目标是什么?

  4. What are the actor’s goals?

  5. 故事开始之前应该存在哪些先决条件?

  6. What preconditions should exist before the story begins?

  7. 演员执行哪些主要任务或职能?

  8. What main tasks or functions are performed by the actor?

  9. 在描述故事时可以考虑哪些例外情况?

  10. What exceptions might be considered as the story is described?

  11. 演员的互动可能有哪些变化?

  12. What variations in the actor’s interaction are possible?

  13. 参与者将获取、产生或改变哪些系统信息?

  14. What system information will the actor acquire, produce, or change?

  15. 参与者是否必须向系统通报外部环境的变化?

  16. Will the actor have to inform the system about changes in the external environment?

  17. 参与者希望从系统获得什么信息?

  18. What information does the actor desire from the system?

  19. 演员是否希望获知意外的变化?

  20. Does the actor wish to be informed about unexpected changes?

回顾基本的SafeHome要求,我们定义了四个参与者:房主(用户)、设置管理员(可能与房主是同一个人,但扮演不同的角色)、传感器(连接到系统的设备)以及监控和响应子系统(监控SafeHome家庭安全功能的中央站)。出于本示例的目的,我们仅考虑房主参与者。房主参与者使用警报控制面板、平板电脑或手机以不同方式与家庭安全功能进行交互

Recalling basic SafeHome requirements, we define four actors: homeowner (a user), setup manager (likely the same person as homeowner, but playing a different role), sensors (devices attached to the system), and the monitoring and response subsystem (the central station that monitors the SafeHome home security function). For the purposes of this example, we consider only the homeowner actor. The homeowner actor interacts with the home security function in different ways using either the alarm control panel, a tablet, or a cell phone.

房主:

The homeowner:

  1. 输入密码以允许所有其他交互

  2. Enters a password to allow all other interactions

  3. 查询安全区域状态

  4. Inquires about the status of a security zone

  5. 查询传感器的状态

  6. Inquires about the status of a sensor

  7. 紧急情况下按下紧急按钮

  8. Presses the panic button in an emergency

  9. 激活和停用安全系统

  10. Activates and deactivates the security system

考虑到房主使用控制面板的情况,系统激活的基本用例如下:

Considering the situation in which the homeowner uses the control panel, the basic use case for system activation follows:

  1. 房主观察SafeHome控制面板(图 7.1)以确定系统是否准备好输入。如果系统未就绪,液晶显示屏上会显示未就绪消息,房主必须关闭门窗,以使未就绪消息消失。(未就绪消息意味着传感器已打开,即门或窗已打开。)第116页

  2. The homeowner observes the SafeHome control panel (Figure 7.1) to determine if the system is ready for input. If the system is not ready, a not ready message is displayed on the LCD display, and the homeowner must physically close windows or doors so that the not ready message disappears. (A not ready message implies that a sensor is open, i.e., that a door or window is open.)Page 116

  3. 房主使用键盘输入四位数密码。该密码将与系统中存储的有效密码进行比较。如果密码不正确,控制面板将发出一声蜂鸣声并自行重置以进行其他输入。如果密码正确,控制面板等待进一步操作。

  4. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

  5. 房主选择并键入“stay”或“away”(见图7.1)来激活系统。保持仅激活周边传感器(内部运动检测传感器被停用)。离开会激活所有传感器。

  6. The homeowner selects and keys in “stay” or “away” (see Figure 7.1) to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors.

  7. 当激活发生时,房主可以观察到红色警报灯。

  8. When activation occurs, a red alarm light can be observed by the homeowner.

图7.1 SafeHome 控制面板

Figure 7.1 SafeHome control panel

基本用例呈现了一个高级用户故事,描述了参与者和系统之间的交互。

The basic use case presents a high-level user story that describes the interaction between the actor and the system.

在许多情况下,用例被进一步阐述以提供有关交互的更多细节。例如,Cockburn [Coc01b] 建议使用以下模板来详细描述用例:

In many instances, uses cases are further elaborated to provide considerably more detail about the interaction. For example, Cockburn [Coc01b] suggests the following template for detailed descriptions of use cases:

使用案例: 启动监控
主要演员: 房主。
背景下的目标: 设置系统在房主离开房屋或留在室内时监控传感器。
前提条件:          系统已编程设置密码并识别各种传感器。
扳机:          房主决定对系统进行“设置”,即开启报警功能。

第117页设想:

Page 117Scenario:

  1. 房主观察控制面板。

  2. Homeowner observes control panel.

  3. 房主输入密码。

  4. Homeowner enters password.

  5. 房主选择“留下”或“离开”。

  6. Homeowner selects “stay” or “away.”

  7. 房主观察到红色警报灯,表明SafeHome已布防。

  8. Homeowner observes red alarm light to indicate that SafeHome has been armed.

例外情况:

Exceptions:

  1. 控制面板未就绪:房主检查所有传感器以确定哪些传感器已打开,然后将其关闭。

  2. Control panel is not ready: Homeowner checks all sensors to determine which are open and then closes them.

  3. 密码不正确(控制面板发出一声蜂鸣声):房主重新输入正确的密码。

  4. Password is incorrect (control panel beeps once): Homeowner reenters correct password.

  5. 无法识别密码:必须联系监控和响应子系统重新编程密码。

  6. Password not recognized: Monitoring and response subsystem must be contacted to reprogram password.

  7. 选择停留:控制面板发出两声蜂鸣声,停留灯亮起;周边传感器被激活。

  8. Stay is selected: Control panel beeps twice, and a stay light is lit; perimeter sensors are activated.

  9. 选择离开:控制面板蜂鸣三声,离开灯亮;所有传感器均被激活。

  10. Away is selected: Control panel beeps three times, and an away light is lit; all sensors are activated.

优先事项:           必不可少,必须落实
有空的时候:           第一次增量
使用频率:           每天多次
演员频道:           通过控制面板界面
次要演员:           支持技术人员、传感器

次要参与者的渠道:

Channels to secondary actors:

  1. 支持技术人员:电话线

  2. Support technician: phone line

  3. 传感器:硬连线和射频接口

  4. Sensors: hardwired and radio frequency interfaces

开放式问题:

Open issues:

  1. 是否应该有一种方法可以在不使用密码或使用缩写密码的情况下激活系统?

  2. Should there be a way to activate the system without the use of a password or with an abbreviated password?

  3. 控制面板是否应该显示附加文本消息?

  4. Should the control panel display additional text messages?

  5. 从按下第一个键开始,房主需要多长时间输入密码?

  6. How much time does the homeowner have to enter the password from the time the first key is pressed?

  7. 有没有办法在系统实际激活之前将其停用?

  8. Is there a way to deactivate the system before it actually activates?

其他房主互动的用例将以类似的方式开发。仔细审查每个用例非常重要。如果交互的某些元素不明确,则对用例的审查可能会表明存在问题。用例通常被非正式地编写为用户故事。但是,使用此处显示的模板有助于确保您已解决所有关键问题。这对于利益相关者关心用户安全的系统非常重要。第118页

Use cases for other homeowner interactions would be developed in a similar manner. It is important to review each use case with care. If some element of the interaction is ambiguous, it is likely that a review of the use case will indicate a problem. Use cases are often written informally as user stories. However, using the template shown here helps to ensure that you’ve addressed all key issues. This is very important for systems where user safety or security is a stakeholder concern.Page 118

7.5 建立分析模型

7.5 Building the Analysis Model

分析模型的目的是为基于计算机的系统提供所需信息、功能和行为领域的描述。随着您对要构建的系统的了解更多,并且利益相关者对他们真正需要的了解更多,模型会动态变化。因此,分析模型是任何给定时间的需求快照。你应该期待它会改变。

The intent of the analysis model is to provide a description of the required informational, functional, and behavioral domains for a computer-based system. The model changes dynamically as you learn more about the system to be built, and as stakeholders understand more about what they really require. For that reason, the analysis model is a snapshot of requirements at any given time. You should expect it to change.

随着分析模型的发展,某些元素将变得相对稳定,为后续的设计任务提供坚实的基础。然而,模型的其他元素可能更加不稳定,这表明利益相关者尚未完全理解系统的需求。如果您的团队发现在项目进入设计和施工阶段时没有使用分析模型的某些元素,则将来不应创建这些元素,也不应随着当前项目中的需求变化而维护这些元素。第 8 章详细介绍了分析模型和用于构建该模型的方法。我们将在接下来的部分中进行简要概述。

As the analysis model evolves, certain elements will become relatively stable, providing a solid foundation for the design tasks that follow. However, other elements of the model may be more volatile, indicating that stakeholders do not yet fully understand requirements for the system. If your team finds that it does not use certain elements of the analysis model as the project moves to design and construction, those elements should not be created in the future and should not be maintained as the requirements change in the current project. The analysis model and the methods that are used to build it are presented in detail in Chapter 8. We present a brief overview in the sections that follow.

第119页

Page 119

7.5.1 分析模型的要素

7.5.1 Elements of the Analysis Model

有很多方法可以查看基于计算机的系统的要求。一些软件人员认为,最好选择一种表示模式(例如,用例)并将其应用于排除所有其他模式。其他从业者认为,使用几种不同的表示模式来描述分析模型是值得的。使用不同的表示模式迫使您从不同的角度考虑需求,这种方法更有可能发现遗漏、不一致和模糊之处。让利益相关者参与进来总是一个好主意。做到这一点的最佳方法之一是让每个利益相关者编写描述如何使用软件的用例。本章介绍了大多数分析模型所共有的一组通用元素。

There are many ways to look at the requirements for a computer-based system. Some software people argue that it’s best to select one mode of representation (e.g., the use case) and apply it to the exclusion of all other modes. Other practitioners believe that it’s worthwhile to use several different modes of representation to depict the analysis model. Using different modes of representation forces you to consider requirements from different viewpoints—an approach that has a higher probability of uncovering omissions, inconsistencies, and ambiguity. It is always a good idea to get stakeholders involved. One of the best ways to do this is to have each stakeholder write use cases that describe how the software will be used. A set of generic elements common to most analysis models is introduced in this chapter.

基于场景的元素。需求模型的基于场景的元素通常是所开发模型的第一部分。他们从用户的角度描述系统。例如,基本用户故​​事(第 7.4 节)及其相应的用例图(图 7.2)可能会演变成更复杂的基于模板的用例(第 7.4 节)。因此,它们充当创建其他建模元素的输入。让利益相关者参与进来总是一个好主意。做到这一点的最佳方法之一是让每个利益相关者编写描述如何使用软件的用例。

Scenario-Based Elements. Scenario-based elements of the requirements model are often the first part of the model that is developed. They describe the system from the user’s point of view. For example, basic user stories (Section 7.4) and their corresponding use case diagrams (Figure 7.2) may evolve into more elaborate template-based use cases (Section 7.4). As such, they serve as input for the creation of other modeling elements. It is always a good idea to get stakeholders involved. One of the best ways to do this is to have each stakeholder write use cases that describe how the software will be used.

第120页基于类的元素。每个使用场景都意味着一组对象,这些对象在参与者与系统交互时被操纵。这些对象被分类为类——具有相似属性和共同行为的事物的集合。例如,UML 类图可用于描述SafeHome安全功能的Sensor类(图 7.3)。

Page 120Class-Based Elements. Each usage scenario implies a set of objects that are manipulated as an actor interacts with the system. These objects are categorized into classes—a collection of things that have similar attributes and common behaviors. For example, a UML class diagram can be used to depict a Sensor class for the SafeHome security function (Figure 7.3).

7.3传感器 的类图

Figure 7.3 Class diagram for sensor

请注意,该图列出了传感器的属性(例如,名称、类型)以及可用于修改这些属性的操作(例如,识别、启用)。其他分析建模元素描述了类如何相互协作以及类之间的关系和交互。隔离类的一种方法是在用例脚本中查找描述性名词。至少有一些名词将成为候选类。在用例脚本中找到的动词可以被视为这些类的候选方法。这些技术和其他技术将在第 8 章中进行更详细的讨论。

Note that the diagram lists the attributes of sensors (e.g., name, type) and the operations (e.g., identify, enable) that can be applied to modify these attributes. Other analysis modeling elements depict how classes collaborate with one another and the relationships and interactions among classes. One way to isolate classes is to look for descriptive nouns in a use case script. At least some of the nouns will be candidate classes. The verbs found in the use case script may be considered candidate methods for these classes. These and other techniques are discussed in more detail in Chapter 8.

行为要素。基于计算机的系统的行为会对所选择的设计和所应用的实现方法产生深远的影响。因此,需求模型必须提供描述行为的建模元素。

Behavioral Elements. The behavior of a computer-based system can have a profound effect on the design that is chosen and the implementation approach that is applied. Therefore, the requirements model must provide modeling elements that depict behavior.

状态是通过描述系统的状态和导致系统改变状态的事件来表示系统行为的一种方法。状态是任何外部可观察行为模式。此外,状态图指示事件发生时采取什么操作(例如,流程激活)。外部刺激(事件)导致状态之间的转换。

The state diagram is one method for representing the behavior of a system by depicting its states and the events that cause the system to change state. A state is any externally observable mode of behavior. In addition, the state diagram indicates what actions (e.g., process activations) are taken when events occur. External stimuli (events) cause transitions between states.

第121页为了说明状态图的用法,请考虑SafeHome控制面板中嵌入的负责读取用户输入的软件。UML 状态图表示法的示例如图7.4所示。行为建模的进一步讨论将在第 8 章中进行。

Page 121To illustrate the use of a state diagram, consider software embedded within the SafeHome control panel that is responsible for reading user input. An example of UML state diagram notation is shown in Figure 7.4. Further discussion of behavioral modeling is presented in Chapter 8.

图7.4 UML状态图表示

Figure 7.4 UML state diagram notation

第122页

Page 122

7.5.2 分析模式

7.5.2 Analysis Patterns

任何对多个软件项目进行过需求工程的人都会注意到,某些问题会在特定应用程序域内的所有项目中重复出现。这些分析模式[Fow97]提出了应用程序域内的解决方案(例如,类、函数、行为),这些解决方案可以在对许多应用程序进行建模时重用。

Anyone who has done requirements engineering on more than a few software projects notices that certain problems reoccur across all projects within a specific application domain. These analysis patterns [Fow97] suggest solutions (e.g., a class, a function, a behavior) within the application domain that can be reused when modeling many applications.

分析模式通过参考模式名称集成到分析模型中。它们还存储在存储库中,以便需求工程师可以使用搜索工具来查找和重用它们。有关分析模式(以及其他类型的模式)的信息在标准模板 [Gey01] 中提供,第 14 章将更详细地讨论该模板。第 8 章介绍了分析模式的示例以及该主题的进一步讨论。

Analysis patterns are integrated into the analysis model by reference to the pattern name. They are also stored in a repository so that requirements engineers can use search facilities to find and reuse them. Information about an analysis pattern (and other types of patterns) is presented in a standard template [Gey01] that is discussed in more detail in Chapter 14. Examples of analysis patterns and further discussion of this topic are presented in Chapter 8.

7.6 谈判要求

7.6 Negotiating Requirements

在理想的情况下,需求工程任务(启动、启发和细化)足够详细地确定客户需求,以继续进行后续的软件工程活动。不幸的是,这种情况很少发生。您可能必须与一个或多个利益相关者进行谈判。在大多数情况下,利益相关者被要求平衡功能、性能和其他产品或系统特性与成本和上市时间。这些谈判的目的是制定一个项目计划,满足利益相关者的需求,同时反映软件团队面临的现实限制(例如,时间、人员、预算)。

In an ideal world, the requirements engineering tasks (inception, elicitation, and elaboration) determine customer requirements in sufficient detail to proceed to subsequent software engineering activities. Unfortunately, this rarely happens. You may have to enter into negotiations with one or more stakeholders. In most cases, stakeholders are asked to balance functionality, performance, and other product or system characteristics against cost and time to market. The intent of these negotiations is to develop a project plan that meets stakeholder needs while at the same time reflecting the real-world constraints (e.g., time, people, budget) that have been placed on the software team.

最好的谈判力求“双赢”的结果。也就是说,利益相关者通过获得最能满足其需求的系统或产品而获胜,而您(作为软件团队的成员)通过努力实现现实且可实现的预算和截止日期而获胜。

The best negotiations strive for a “win-win” result. That is, stakeholders win by getting the system or product that satisfies most their needs, and you (as a member of the software team) win by working to realistic and achievable budgets and deadlines.

Fricker [Fri10] 和他的同事建议用称为握手的双向通信过程来取代传统的将需求规范移交给软件团队的方式握手可能是实现双赢的一种方式。在握手过程中,软件团队提出需求解决方案,描述其影响,并向客户代表传达其意图。客户代表审查提议的解决方案,重点关注缺失的功能并寻求对新要求的澄清。如果客户接受建议的解决方案,则确定需求足够好握手往往会改善变体的识别、分析和选择,并促进双赢的谈判。

Fricker [Fri10] and his colleagues suggest replacing the traditional handoff of requirements specifications to software teams with a bidirectional communication process called handshaking. Handshaking might be one way to accomplish a win-win result. In handshaking, the software team proposes solutions to requirements, describes their impact, and communicates their intentions to customer representatives. The customer representatives review the proposed solutions, focusing on missing features and seeking clarification of novel requirements. Requirements are determined to be good enough if the customers accept the proposed solution. Handshaking tends to improve identification, analysis, and selection of variants and promotes win-win negotiation.

7.7 需求监控

7.7 Requirements Monitoring

渐进式开发是很常见的。这意味着用例不断发展,为每个新的软件增量开发新的测试用例,并且在整个项目中不断集成源代码。当使用增量开发时,需求监控非常有用。它包含五个任务:(1)分布式调试发现错误并确定其原因,(2)运行时验证确定软件是否符合其规范,(3)运行时验证评估不断发展的软件是否满足用户目标,(4)业务活动监控评估系统是否满足业务目标,(5)演进和协同设计随着系统的演进向利益相关者提供信息。

Incremental development is commonplace. This means that use cases evolve, new test cases are developed for each new software increment, and continuous integration of source code occurs throughout a project. Requirements monitoring can be extremely useful when incremental development is used. It encompasses five tasks: (1) distributed debugging uncovers errors and determines their cause, (2) run-time verification determines whether software matches its specification, (3) run-time validation assesses whether the evolving software meets user goals, (4) business activity monitoring evaluates whether a system satisfies business goals, and (5) evolution and codesign provides information to stakeholders as the system evolves.

增量开发意味着需要增量验证。需求监控通过根据正在使用的系统分析用户目标模型来支持持续验证。例如,监控系统可能会持续评估用户满意度并使用反馈来指导渐进式改进[Rob10]。

Incremental development implies the need for incremental validation. Requirements monitoring supports continuous validation by analyzing user goal models against the system in use. For example, a monitoring system might continuously assess user satisfaction and use feedback to guide incremental improvements [Rob10].

7.8 验证需求

7.8 Validating Requirements

创建需求模型的每个元素时,都会检查其是否存在不一致、遗漏和歧义。即使对于敏捷流程模型也是如此,其中需求往往被编写为用户故事和/或测试用例。模型所代表的需求由利益相关者确定优先级,并分组在将作为软件增量实现的需求包中。对需求模型的审查解决了以下问题:第124页

As each element of the requirements model is created, it is examined for inconsistency, omissions, and ambiguity. This is true even for agile process models where requirements tend to be written as user stories and/or test cases. The requirements represented by the model are prioritized by stakeholders and grouped within requirements packages that will be implemented as software increments. A review of the requirements model addresses the following questions:Page 124

  1. 每项要求是否与系统或产品的总体目标一致?

  2. Is each requirement consistent with the overall objectives for the system or product?

  3. 所有需求是否都已在适当的抽象级别上指定?也就是说,某些要求是否提供了现阶段不合适的技术细节级别?

  4. Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

  5. 该需求是否确实必要,或者它是否代表了对于系统目标而言可能并不重要的附加功能?

  6. Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

  7. 每个要求是否有界限且明确?

  8. Is each requirement bounded and unambiguous?

  9. 每个需求都有归属吗?也就是说,是否为每项要求注明了来源(通常是特定个人)?

  10. Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

  11. 任何要求是否与其他要求冲突?

  12. Do any requirements conflict with other requirements?

  13. 每项要求是否可以在容纳系统或产品的技术环境中实现?

  14. Is each requirement achievable in the technical environment that will house the system or product?

  15. 每个需求一旦实施后是否可以测试?

  16. Is each requirement testable, once implemented?

  17. 需求模型是否正确反映了要构建的系统的信息、功能和行为?

  18. Does the requirements model properly reflect the information, function, and behavior of the system to be built?

  19. 需求模型是否已以逐渐公开有关系统的更详细信息的方式进行“分区”?

  20. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system?

  21. 是否使用需求模式来简化需求模型?所有模式都经过正确验证吗?所有图案是否符合客户要求?

  22. Have requirements patterns been used to simplify the requirements model? Have all patterns been properly validated? Are all patterns consistent with customer requirements?

应该提出并回答这些问题和其他问题,以确保需求模型准确反映利益相关者的需求,并为设计提供坚实的基础。

These and other questions should be asked and answered to ensure that the requirements model is an accurate reflection of stakeholder needs and that it provides a solid foundation for design.

7.9 总结

7.9 Summary

进行需求工程任务,为设计和施工奠定坚实的基础。需求工程发生在为通用软件过程定义的通信和建模活动期间。七项需求工程活动——启动、启发、阐述、协商、规范、验证和管理——由软件团队的成员和产品利益相关者进行。

Requirements engineering tasks are conducted to establish a solid foundation for design and construction. Requirements engineering occurs during the communication and modeling activities that have been defined for the generic software process. Seven requirements engineering activities—inception, elicitation, elaboration, negotiation, specification, validation, and management—are conducted by members of the software team and product stakeholders.

在项目开始时,利益相关者建立基本的问题需求,定义首要的项目约束,并解决系统必须具备的主要特性和功能,以实现其目标。这些信息在启发过程中得到完善和扩展,这是一种利用便利会议和开发使用场景(用户故事)的需求收集活动。

At project inception, stakeholders establish basic problem requirements, define overriding project constraints, and address major features and functions that must be present for the system to meet its objectives. This information is refined and expanded during elicitation—a requirements gathering activity that makes use of facilitated meetings and the development of usage scenarios (user stories).

细化进一步扩展了模型中的需求——基于场景、基于活动、基于类和行为元素的集合。该模型可以参考分析模式、已在不同应用程序中重复出现的问题域的特征。第125页

Elaboration further expands requirements in a model—a collection of scenario-based, activity-based, class-based, and behavioral elements. The model may reference analysis patterns, characteristics of the problem domain that have been seen to reoccur across different applications.Page 125

当需求被识别并创建需求模型时,软件团队和其他项目利益相关者就每个需求的优先级、可用性和相对成本进行协商。此次谈判的目的是制定一个切合实际的项目计划。每个需求都需要根据客户需求进行验证,以确保构建正确的系统。

As requirements are identified and the requirements model is being created, the software team and other project stakeholders negotiate the priority, availability, and relative cost of each requirement. The intent of this negotiation is to develop a realistic project plan. Each requirement needs to be validated against customer needs to ensure that the right system is to be built.

问题与思考点

Problems and Points to Ponder

7.1. 为什么许多软件开发人员对需求工程重视不够?有没有什么情况可以跳过它?

7.1. Why is it that many software developers don’t pay enough attention to requirements engineering? Are there ever circumstances where you can skip it?

7.2. 您有责任征求一位客户的要求,该客户告诉您他太忙而无法与您见面。你该怎么办?

7.2. You have been given the responsibility to elicit requirements from a customer who tells you he is too busy to meet with you. What should you do?

7.3. 讨论当必须从三四个不同的客户处获取需求时出现的一些问题。

7.3. Discuss some of the problems that occur when requirements must be elicited from three or four different customers.

7.4. 您的老师会将班级分成四到六名学生的小组。该团队的一半人将担任营销部门,一半人将担任软件工程部的角色。您的工作是定义本章中描述的SafeHome安全功能的要求。使用本章中介绍的指南召开需求收集会议。

7.4. Your instructor will divide the class into groups of four or six students. Half of the group will play the role of the marketing department and half will take on the role of software engineering. Your job is to define requirements for the SafeHome security function described in this chapter. Conduct a requirements gathering meeting using the guidelines presented in this chapter.

7.5。为以下活动之一开发完整的用例:

7.5. Develop a complete use case for one of the following activities:

  1. 在 ATM 机上取款

  2. Making a withdrawal at an ATM

  3. 使用您的签账卡在餐厅用餐

  4. Using your charge card for a meal at a restaurant

  5. 使用在线书店搜索书籍(关于特定主题)

  6. Searching for books (on a specific topic) using an online bookstore

7.6。为问题 7.5中列出的活动之一编写一个用户故事。

7.6. Write a user story for one of the activities listed in Problem 7.5.

7.7. 考虑您在问题 7.5中创建的用例,并为应用程序编写一个非功能性需求。

7.7. Consider the use case you created in Problem 7.5, and write a nonfunctional requirement for the application.

7.8。使用第 7.5.2 节中提供的模板,为以下应用领域建议一种或多种分析模式:

7.8. Using the template presented in Section 7.5.2, suggest one or more analysis patterns for the following application domains:

  1. 电子邮件软件。

  2. E-mail software.

  3. 互联网浏览器。

  4. Internet browsers.

  5. 移动应用程序创建软件。

  6. Mobile app creation software.

7.9。在需求工程活动期间的谈判中,双赢意味着什么?

7.9. What does win-win mean in the context of negotiation during the requirements engineering activity?

7.10。当需求验证发现错误时,您认为会发生什么?谁参与纠正错误?

7.10. What do you think happens when requirement validation uncovers an error? Who is involved in correcting the error?

章节

chapter

第126页

Page 126

8需求建模——推荐的方法

8 Requirements Modeling—A Recommended Approach

书面文字是一种极好的沟通工具,但它不一定是表达计算机软件需求的最佳方式。在技​​术层面上,软件工程从一系列建模任务开始,这些任务产生需求规范和要构建的软件的设计表示。需求模型实际上是构成系统第一个技术表示的一组模型。软件工程师通常更喜欢包含复杂模型关系的图形表示。

The written word is a wonderful vehicle for communication, but it is not necessarily the best way to represent the requirements for computer software. At a technical level, software engineering begins with a series of modeling tasks that lead to a specification of requirements and a design representation for the software to be built. The requirements model is actually a set of models that make up the first technical representation of a system. Software engineers often prefer to include graphical representations of complex model relationships.

第127页对于某些类型的软件,用户故事(第 7.3.2 节)可能是唯一需要的需求建模表示。对于其他情况,可以开发正式用例(第 7.4 节)和基于类的模型(第 8.3 节)。基于类的建模表示系统将操作的对象、将应用于对象以实现操作的操作(也称为方法服务)、对象之间的关系(某些层次结构)以及对象之间发生的协作。定义的类。基于类的方法可用于创建非技术涉众可以理解的应用程序表示。

Page 127For some types of software, a user story (Section 7.3.2) may be the only requirements modeling representation that is required. For others, formal use cases (Section 7.4) and class-based models (Section 8.3) may be developed. Class-based modeling represents the objects that the system will manipulate, the operations (also called methods or services) that will be applied to the objects to effect the manipulation, relationships (some hierarchical) between the objects, and the collaborations that occur between the classes that are defined. Class-based methods can be used to create a representation of an application that can be understood by nontechnical stakeholders.

在其他情况下,复杂的应用程序要求可能需要检查应用程序如何响应内部或外部事件。这些行为也需要建模(第 8.5 节)。UML 图已成为以图形方式对模型元素关系和行为进行建模分析的标准软件工程手段。随着需求模型的完善和扩展,它演变成软件工程师在创建软件设计时可以使用的规范。

In still other situations, complex application requirements may demand an examination of how an application behaves in reaction to either internal or external events. These behaviors need to be modeled (Section 8.5) as well. UML diagrams have become a standard software engineering means of modeling analysis model element relationships and behaviors graphically. As the requirements model is refined and expanding, it evolves into a specification that can be used by software engineers in the creation of the software design.

在建模需求时要记住的重要一点是仅创建开发团队将使用的模型。如果在项目的需求分析阶段早期开发的模型在设计和实现阶段没有被引用,那么它们可能不值得更新。以下各节介绍了一系列非正式指南,有助于创建和表示需求模型。

The important thing to keep in mind when modeling requirements is to only create the models that will be used by the development team. If models developed early in a requirements analysis phase of a project are not referred to during the design and implementation phases, they may not be worth updating. The sections that follow present a series of informal guidelines that will assist in the creation and representation of requirements models.

8.1 需求分析

8.1 Requirements Analysis

需求分析产生软件操作特性的规范,指示软件与其他系统元素的接口,并建立软件必须满足的约束。需求分析允许您(无论您是否被称为软件工程师、分析师建模)详细说明在需求工程的起始、启发和协商任务期间建立的基本需求(第 7 章)。

Requirements analysis results in the specification of software’s operational characteristics, indicates software’s interface with other system elements, and establishes constraints that software must meet. Requirements analysis allows you (regardless of whether you’re called a software engineer, an analyst, or a modeler) to elaborate on basic requirements established during the inception, elicitation, and negotiation tasks that are part of requirements engineering (Chapter 7).

需求建模操作会产生以下一种或多种类型的模型:

The requirements modeling action results in one or more of the following types of models:

  • 从各种系统“参与者”的角度来看基于场景的需求模型。

  • Scenario-based models of requirements from the point of view of various system “actors.”

  • 面向类的模型,表示面向对象的类(属性和操作)以及类如何协作以实现系统需求。

  • Class-oriented models that represent object-oriented classes (attributes and operations) and how classes collaborate to achieve system requirements.

  • 行为模型描述软件如何对内部或外部“事件”做出反应。

  • Behavioral models that depict how the software reacts to internal or external “events.”

  • 描述问题的信息域的数据模型。

  • Data models that depict the information domain for the problem.

  • 面向流的模型,代表系统的功能元素以及它们在系统中移动时如何转换数据。

  • Flow-oriented models that represent the functional elements of the system and how they transform data as they move through the system.

这些模型为软件设计人员提供了可以转换为架构级、界面级和组件级设计的信息。最后,需求模型(和软件需求规范)为开发人员和客户提供了在软件构建后评估质量的方法。第128页

These models provide a software designer with information that can be translated to architectural-, interface-, and component-level designs. Finally, the requirements model (and the software requirements specification) provides the developer and the customer with the means to assess quality once software is built.Page 128

在本节中,我们将重点关注基于场景的建模——这是一种在软件工程社区中非常流行的技术。在第 8.3 节第 8.5节中,我们考虑基于类的建模和行为建模。在过去的十年中,流和数据建模已经越来越不常用,而基于场景和基于类的方法,辅以行为方法却越来越受欢迎。1

In this section, we focus on scenario-based modeling—a technique that is very popular throughout the software engineering community. In Sections 8.3 and 8.5 we consider class-based modeling and behavioral modeling. Over the past decade, flow and data modeling have become less commonly used, while scenario and class-based methods, supplemented with behavioral approaches have grown in popularity.1

8.1.1 总体目标和理念

8.1.1 Overall Objectives and Philosophy

在整个分析建模过程中,您的主要关注点是做什么,而不是如何。发生哪些用户交互,系统操作哪些对象,系统必须执行哪些功能,系统表现出哪些行为,定义了哪些接口以及应用了哪些约束?2

Throughout analysis modeling, your primary focus is on what, not how. What user interaction occurs, what objects does the system manipulate, what functions must the system perform, what behaviors does the system exhibit, what interfaces are defined, and what constraints apply?2

在前面的章节中,我们注意到现阶段可能无法完成完整的需求规范。客户可能不确定系统的某些方面到底需要什么。开发人员可能不确定特定方法是否能够正确实现功能和性能。这些现实缓解了需求分析和建模的迭代方法。分析师应该对已知的内容进行建模,并使用该模型作为软件增量设计的基础。3

In previous chapters, we noted that complete specification of requirements may not be possible at this stage. The customer may be unsure of precisely what is required for certain aspects of the system. The developer may be unsure that a specific approach will properly accomplish function and performance. These realities mitigate in favor of an iterative approach to requirements analysis and modeling. The analyst should model what is known and use that model as the basis for design of the software increment.3

需求模型必须实现三个主要目标:(1) 描述客户的需求,(2) 为创建软件设计奠定基础,(3) 定义一组需求,一旦设计完成即可对其进行验证。软件已构建。分析模型弥补了描述整个系统或业务功能(软件、硬件、数据、人为元素)的系统级描述与描述软件的应用程序架构、用户界面和软件设计(第 9 章到第 14 章)之间的差距组件级结构。这种关系如图 8.1所示。

The requirements model must achieve three primary objectives: (1) to describe what the customer requires, (2) to establish a basis for the creation of a software design, and (3) to define a set of requirements that can be validated once the software is built. The analysis model bridges the gap between a system-level description that describes overall system or business functionality (software, hardware, data, human elements) and a software design (Chapters 9 through 14) that describes the software’s application architecture, user interface, and component-level structure. This relationship is illustrated in Figure 8.1.

图8.1分析模型作为系统描述和设计 模型之间的桥梁

Figure 8.1 The analysis model as a bridge between the system description and the design model

需要注意的是,需求模型的所有元素都可以直接追溯到设计模型的各个部分。分析和设计建模任务之间的明确划分并不总是可能的。有些设计总是作为分析的一部分发生,有些分析将在设计过程中进行。

It is important to note that all elements of the requirements model will be directly traceable to parts of the design model. A clear division between analysis and design modeling tasks is not always possible. Some design invariably occurs as part of analysis, and some analysis will be conducted during design.

8.1.2 分析经验法则

8.1.2 Analysis Rules of Thumb

创建分析模型时,有几个经验法则 [Arl02] 值得考虑。首先,关注问题或业务领域,同时保持较高的抽象级别。其次,认识到分析模型应该提供对软件的信息域、功能和行为的洞察。第三,将软件架构和非功能细节的考虑推迟到建模活动的后期。此外,了解软件元素与其他元素互连的方式(我们称之为系统耦合)也很重要。第129页

Several rules of thumb [Arl02] are worth considering when creating an analysis model. First, focus on the problem or business domain while keeping the level of abstraction high. Second, recognize that an analysis model should provide insight into the information domain, the function, and the behavior of the software. Third, delay a consideration of software architecture and nonfunctional details until later in the modeling activity. Also, it’s important to be aware of the ways in which elements of the software are interconnnected with other elements (we call this system coupling).Page 129

分析模型的结构必须能够为所有利益相关者提供价值,并且应在不牺牲清晰度的情况下尽可能保持简单。

The analysis model must be structured in a way that provides value to all stakeholders and should be kept as simple as possible without sacrificing clarity.

8.1.3 需求建模原则

8.1.3 Requirements Modeling Principles

在过去的四十年中,已经开发了多种需​​求建模方法。研究人员已经确定了需求分析问题及其原因,并开发了各种建模符号和相应的启发式方法来克服这些问题。每种分析方法都有独特的观点。一组操作原则与分析方法相关:

Over the past four decades, several requirements modeling methods have been developed. Investigators have identified requirements analysis problems and their causes and have developed a variety of modeling notations and corresponding sets of heuristics to overcome them. Each analysis method has a unique point of view. A set of operational principles relates analysis methods:

原则 1.问题的信息域必须被表示和理解。信息包括流入系统的数据(从最终用户、其他系统或外部设备)、流出系统的数据(通过用户界面、网络接口、报告、图形和其他方式),以及收集和组织永久维护的数据的数据存储。

Principle 1. The information domain of a problem must be represented and understood. The information domain encompasses the data that flow into the system (from end users, other systems, or external devices), the data that flow out of the system (via the user interface, network interfaces, reports, graphics, and other means), and the data stores that collect and organize the data that are maintained permanently.

原则 2.必须定义软件执行的功能。软件功能为最终用户和那些为用户可见的功能提供内部支持的用户提供直接的好处。某些函数会转换流入系统的数据。在其他情况下,功能会影响对内部软件处理或外部系统元素的某种程度的控制。第130页

Principle 2. The functions that the software performs must be defined. Software functions provide direct benefit to end users and those that provide internal support for those features that are user visible. Some functions transform data that flow into the system. In other cases, functions effect some level of control over internal software processing or external system elements.Page 130

原则 3.软件的行为(作为外部事件的结果)必须被表示。计算机软件的行为是由其与外部环境的交互驱动的。最终用户提供的输入、外部系统提供的控制数据或通过网络收集的监控数据都会导致软件以特定方式运行。

Principle 3. The behavior of the software (as a consequence of external events) must be represented. The behavior of computer software is driven by its interaction with the external environment. Input provided by end users, control data provided by an external system, or monitoring data collected over a network all cause the software to behave in a specific way.

原则 4.描述信息、功能和行为的模型必须以分层(或分层)方式揭示细节的方式进行划分。需求建模是软件工程问题解决的第一步。它可以让您更好地理解问题并为解决方案(设计)奠定基础。复杂的问题很难完全解决。因此,您应该使用分而治之的策略。一个大的、复杂的问题被划分为子问题,直到每个子问题都相对容易理解。这个概念称为分区关注点分离,它是需求建模中的关键策略。

Principle 4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Requirements modeling is the first step in software engineering problem solving. It allows you to better understand the problem and establishes a basis for the solution (design). Complex problems are difficult to solve in their entirety. For this reason, you should use a divide-and-conquer strategy. A large, complex problem is divided into subproblems until each subproblem is relatively easy to understand. This concept is called partitioning or separation of concerns, and it is a key strategy in requirements modeling.

原则 5.分析任务应该从基本信息转向实施细节。分析建模首先从最终用户的角度描述问题。描述问题的“本质”时没有考虑如何实施解决方案。例如,视频游戏要求玩家“指示”主角进入危险的迷宫时应朝哪个方向前进。这就是问题的本质。实现细节(通常描述为设计模型的一部分)指示了本质将如何实现。对于视频游戏,可以使用语音输入。或者,可以键入键盘命令,可以将游戏手柄操纵杆(或鼠标)指向特定方向,可以在空中挥动运动敏感设备,或者直接读取玩家身体或眼球运动的设备可以使用。

Principle 5. The analysis task should move from essential information toward implementation detail. Analysis modeling begins by describing the problem from the end-user’s perspective. The “essence” of the problem is described without any consideration of how a solution will be implemented. For example, a video game requires that the player “instruct” its protagonist on what direction to proceed as she moves into a dangerous maze. That is the essence of the problem. Implementation detail (normally described as part of the design model) indicates how the essence will be implemented. For the video game, voice input might be used. Alternatively, a keyboard command might be typed, a game pad joystick (or mouse) might be pointed in a specific direction, a motion-sensitive device might be waved in the air, or a device that reads the player’s body or eye movements directly can be used.

通过应用这些原则,软件工程师可以系统地解决问题。但这些原则如何应用于实践呢?这个问题将在本章剩余部分得到解答。

By applying these principles, a software engineer approaches a problem systematically. But how are these principles applied in practice? This question will be answered in the remainder of this chapter.

8.2 基于场景的建模

8.2 Scenario-Based Modeling

尽管基于计算机的系统或产品的成功可以通过多种方式来衡量,但用户满意度是最重要的。如果您了解最终用户(和其他参与者)希望如何与系统交互,您的软件团队将能够更好地正确描述需求并构建有意义的分析和设计模型。使用 UML 4对需求建模首先以用例图、活动图和序列图的形式创建场景。第131页

Although the success of a computer-based system or product is measured in many ways, user satisfaction resides at the top of the list. If you understand how end users (and other actors) want to interact with a system, your software team will be better able to properly characterize requirements and build meaningful analysis and design models. Using UML4 to model requirements begins with the creation of scenarios in the form of use case diagrams, activity diagrams, and sequence diagrams.Page 131

8.2.1 参与者和用户概况

8.2.1 Actors and User Profiles

UML参与者对与系统对象交互的实体进行建模。参与者可以代表人类利益相关者或外部硬件在通过交换信息与系统对象交互时所扮演的角色。如果物理实体承担与实现不同系统功能相关的多个角色,则单个物理实体可以由多个参与者来描绘。

A UML actor models an entity that interacts with a system object. Actors may represent roles played by human stakeholders or external hardware as they interact with system objects by exchanging information. A single physical entity may be portrayed by several actors if the physical entity takes on several roles that are relevant to realizing different system functions.

UML概要文件提供了一种将现有模型扩展到其他域或平台的方法。这可能允许您修改基于 Web 的系统模型并针对各种移动平台对系统进行建模。配置文件还可以用于从不同用户的角度对系统进行建模。例如,系统管理员对自动柜员机功能的看法可能与最终用户不同。

A UML profile provides a way of extending an existing model to other domains or platforms. This might allow you to revise the model of a Web-based system and model the system for various mobile platforms. Profiles might also be used to model the system from the viewpoints of different users. For example, system administrators may have a different view of the functionality of an automated teller machine than end users.

8.2.2 创建用例

8.2.2 Creating Use Cases

第 7 章中,我们讨论了用户故事,以此总结利益相关者对如何与提议的系统交互的看法。然而,它们是用简单的英语或利益相关者使用的语言编写的。在开始创建软件之前,开发人员需要更精确的方法来描述这种交互。Alistair Cockburn 将用例描述为“行为契约”[Coc01b]。正如我们在第 7 章中讨论的,“契约”定义了参与者5使用基于计算机的系统来实现某些目标的方式。换句话说,用例捕获系统本身内信息的生产者和消费者之间发生的交互。在本节中,我们将研究如何开发初步用例作为分析建模活动的一部分。6

In Chapter 7, we discussed user stories as a way of summarizing the stakeholders’ perspective on how they will interact with the proposed system. However, they are written in plain English or the language used by the stakeholders. Developers need more precise means of describing this interaction before beginning to create the software. Alistair Cockburn characterizes a use case as a “contract for behavior” [Coc01b]. As we discussed in Chapter 7, the “contract” defines the way in which an actor5 uses a computer-based system to accomplish some goal. In other words, a use case captures the interactions that occur between producers and consumers of information within the system itself. In this section, we examine how preliminary use cases are developed as part of the analysis modeling activity.6

第 7 章中,我们注意到用例从定义的参与者的角度以简单的语言描述了特定的使用场景。但是你怎么知道(1)要写什么,(2)要写多少,(3)描述要详细到什么程度,以及(4)如何组织描述?如果用例要提供作为建模工具的价值,则必须回答这些问题。

In Chapter 7, we noted that a use case describes a specific usage scenario in straightforward language from the point of view of a defined actor. But how do you know (1) what to write about, (2) how much to write about it, (3) how detailed to make your description, and (4) how to organize the description? These are the questions that must be answered if use cases are to provide value as a modeling tool.

写什么?前两项需求工程任务(启动和启发)为您提供开始编写用例所需的信息。需求收集会议和其他需求工程机制用于识别利益相关者、定义问题范围、指定总体运营目标、建立优先级、概述所有已知的功能需求,并描述系统将操纵的事物(对象)。

What to Write About? The first two requirements engineering tasks—inception and elicitation—provide you with the information you’ll need to begin writing use cases. Requirements gathering meetings and other requirements engineering mechanisms are used to identify stakeholders, define the scope of the problem, specify overall operational goals, establish priorities, outline all known functional requirements, and describe the things (objects) that will be manipulated by the system.

要开始开发一组用例,请列出特定参与者执行的功能或活动。您可以通过与利益相关者的对话,或者通过对作为需求建模的一部分开发的活动图(第 8.4 节)的评估,从所需的系统功能列表中获取这些信息。第132页

To begin developing a set of use cases, list the functions or activities performed by a specific actor. You can obtain these from a list of required system functions, through conversations with stakeholders, or by an evaluation of activity diagrams (Section 8.4) developed as part of requirements modeling.Page 132

侧栏中讨论的SafeHome家庭监控功能(子系统)标识了由房主参与者执行的以下功能(缩写列表

The SafeHome home surveillance function (subsystem) discussed in the sidebar identifies the following functions (an abbreviated list) that are performed by the homeowner actor:

  • 选择要查看的相机。

  • Select camera to view.

  • 请求所有摄像机的缩略图。

  • Request thumbnails from all cameras.

  • 在设备窗口中显示摄像机视图。

  • Display camera views in a device window.

  • 控制特定摄像机的平移和缩放。

  • Control pan and zoom for a specific camera.

  • 有选择地记录相机输出。第133页

  • Selectively record camera output.Page 133

  • 重播相机输出。

  • Replay camera output.

  • 通过互联网访问摄像机监控。

  • Access camera surveillance via the Internet.

随着与利益相关者(扮演房主的角色)的进一步对话的进展,需求收集团队为每个提到的功能开发用例。一般来说,用例首先以非正式的叙述方式编写。如果需要更多形式,则可以使用第 7 章中提出的结构化格式重写相同的用例。

As further conversations with the stakeholder (who plays the role of a homeowner) progress, the requirements gathering team develops use cases for each of the functions noted. In general, use cases are written first in an informal narrative fashion. If more formality is required, the same use case is rewritten using a structured format like the one proposed in Chapter 7.

为了说明这一点,请考虑通过互联网访问摄像机监控的功能——显示摄像机视图( ACS-DCV )。扮演房主角色的利益相关者可能会编写以下用户故事:

To illustrate, consider the function access camera surveillance via the Internet—display camera views (ACS-DCV). The stakeholder who takes on the role of the homeowner actor might write the following user story:

使用案例:通过互联网访问摄像机监控 - 显示摄像机视图 (ACS-DCV)

Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV)

演员: 房主

Actor: homeowner

如果我在远程位置,我可以使用任何带有适当浏览器软件的移动设备登录SafeHome Products网站。我输入我的用户 ID 和两级密码,一旦通过验证,我就可以访问我安装的SafeHome系统的所有功能。要访问特定的摄像机视图,我从显示的主要功能按钮中选择“监视”。然后我选择“选择相机”,房子的平面图就会显示出来。然后,我选择我感兴趣的摄像机。或者,我可以通过选择“所有摄像机”作为我的查看选项,同时查看所有摄像机的缩略图快照。选择摄像机后,我选择“查看”,每秒一帧的视图会出现在由摄像机 ID 标识的查看窗口中。如果我想切换摄像头,我选择“选择摄像头”,原来的查看窗口就会消失,房子的平面图会再次显示。然后,我选择我感兴趣的相机。出现一个新的查看窗口。

If I’m at a remote location, I can use any mobile device with appropriate browser software to log on to the SafeHome Products website. I enter my user ID and two levels of passwords and once I’m validated, I have access to all functionality for my installed SafeHome system. To access a specific camera view, I select “surveillance” from the major function buttons displayed. I then select “pick a camera” and the floor plan of the house is displayed. I then select the camera that I’m interested in. Alternatively, I can look at thumbnail snapshots from all cameras simultaneously by selecting “all cameras” as my viewing choice. Once I choose a camera, I select “view” and a one-frame-per-second view appears in a viewing window that is identified by the camera ID. If I want to switch cameras, I select “pick a camera,” the original viewing window disappears, and the floor plan of the house is displayed again. I then select the camera that I’m interested in. A new viewing window appears.

叙述性用例的一种变体将交互呈现为用户操作的有序序列。每个动作都表示为一个陈述句。重新审视ACS-DCV函数,您可以编写:

A variation of a narrative use case presents the interaction as an ordered sequence of user actions. Each action is represented as a declarative sentence. Revisiting the ACS-DCV function, you would write:

使用案例:通过互联网访问摄像机监控 - 显示摄像机视图 (ACS-DCV)

Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV)

演员: 房主

Actor: homeowner

  1. 房主登录SafeHome Products网站。

  2. The homeowner logs onto the SafeHome Products website.

  3. 房主输入他或她的用户ID。

  4. The homeowner enters his or her user ID.

  5. 房主输入两个密码(每个密码长度至少为八个字符)。

  6. The homeowner enters two passwords (each at least eight characters in length).

  7. 系统显示所有主要功能按钮。

  8. The system displays all major function buttons.

  9. 房主从主要功能按钮中选择“监控”。

  10. The homeowner selects the “surveillance” from the major function buttons.

  11. 房主选择“选择相机”。

  12. The homeowner selects “pick a camera.”

  13. 系统显示房屋的平面图。

  14. The system displays the floor plan of the house.

  15. 房主从平面图中选择一个摄像头图标。

  16. The homeowner selects a camera icon from the floor plan.

  17. 房主选择“查看”按钮。

  18. The homeowner selects the “view” button.

  19. 系统显示一个由摄像机 ID 标识的查看窗口。

  20. The system displays a viewing window that is identified by the camera ID.

  21. 系统以每秒一帧的速度在观察窗口内显示视频输出。

  22. The system displays video output within the viewing window at one frame per second.

第134页值得注意的是,这个顺序演示没有考虑任何替代交互(叙述是自由流动的,并且确实代表了一些替代方案)。这种类型的用例有时被称为主要场景[Sch98]。

Page 134It is important to note that this sequential presentation does not consider any alternative interactions (the narrative is free flowing and did represent a few alternatives). Use cases of this type are sometimes referred to as primary scenarios [Sch98].

替代交互的描述对于完整理解用例所描述的功能至关重要。因此,主要场景中的每个步骤都是通过提出以下问题来评估的 [Sch98]:

A description of alternative interactions is essential for a complete understanding of the function that is being described by a use case. Therefore, each step in the primary scenario is evaluated by asking the following questions [Sch98]:

  • 此时演员可以采取其他行动吗?

  • Can the actor take some other action at this point?

  • 演员此时是否有可能遇到一些错误情况?如果是这样,那可能是什么?

  • Is it possible that the actor will encounter some error condition at this point? If so, what might it be?

  • 此时,参与者是否可能会遇到一些其他行为(例如,由参与者控制之外的某些事件调用的行为)?如果是这样,那可能是什么?

  • Is it possible that the actor will encounter some other behavior at this point (e.g., behavior that is invoked by some event outside the actor’s control)? If so, what might it be?

这些问题的答案会导致创建一组辅助场景,这些场景是原始用例的一部分,但代表替代行为。例如,考虑前面介绍的主要场景中的步骤 6 和 7:

Answers to these questions result in the creation of a set of secondary scenarios that are part of the original use case but represent alternative behavior. For example, consider steps 6 and 7 in the primary scenario presented earlier:

  1. 房主选择“选择相机”。

  2. The homeowner selects “pick a camera.”

  3. 系统显示房屋的平面图。

  4. The system displays the floor plan of the house.

此时演员可以采取其他行动吗?答案是肯定的参照自由流畅的叙述,演员可以选择同时查看所有摄像机的缩略图快照。因此,一种次要场景可能是“查看所有摄像机的缩略图快照”。

Can the actor take some other action at this point? The answer is yes. Referring to the free-flowing narrative, the actor may choose to view thumbnail snapshots of all cameras simultaneously. Hence, one secondary scenario might be “View thumbnail snapshots for all cameras.”

演员此时是否有可能遇到一些错误情况?基于计算机的系统运行时可能会出现任意数量的错误情况。在这种情况下,我们仅考虑可能是步骤 6 或步骤 7 中描述的操作直接结果的错误条件。同样,问题的答案是肯定的。带有相机图标的平面图可能从未配置过。因此,选择“选择相机”会导致错误情况:“没有为该房屋配置平面图。” 7此错误情况成为次要情况。

Is it possible that the actor will encounter some error condition at this point? Any number of error conditions can occur as a computer-based system operates. In this context, we consider only error conditions that are likely as a direct result of the action described in step 6 or step 7. Again, the answer to the question is yes. A floor plan with camera icons may have never been configured. Hence, selecting “pick a camera” results in an error condition: “No floor plan configured for this house.”7 This error condition becomes a secondary scenario.

此时演员是否可能会遇到其他一些行为?同样,问题的答案是肯定的。当步骤 6 和 7 发生时,系统可能会遇到警报情况。这将导致系统显示特殊的警报通知(类型、位置、系统操作),并为参与者提供与警报性质相关的多个选项。由于这种次要场景几乎可以在所有交互中随时发生,因此它不会成为ACS-DCV用例的一部分。相反,将开发一个单独的用例(遇到警报条件)并根据需要从其他用例中引用。

Is it possible that the actor will encounter some other behavior at this point? Again, the answer to the question is yes. As steps 6 and 7 occur, the system may encounter an alarm condition. This would result in the system displaying a special alarm notification (type, location, system action) and providing the actor with several options relevant to the nature of the alarm. Because this secondary scenario can occur at any time for virtually all interactions, it will not become part of the ACS-DCV use case. Rather, a separate use case—Alarm condition encountered—would be developed and referenced from other use cases as required.

前面段落中描述的每种情况都被描述为用例异常。异常描述了导致系统表现出某种不同行为的情况(失败条件或参与者选择的替代方案)。第135页

Each of the situations described in the preceding paragraphs is characterized as a use case exception. An exception describes a situation (either a failure condition or an alternative chosen by the actor) that causes the system to exhibit somewhat different behavior.Page 135

Cockburn [Coc01b] 建议召开一次“头脑风暴”会议,为每个用例导出一组相当完整的例外情况。除了本节前面建议的三个一般问题外,还应该探讨以下问题:

Cockburn [Coc01b] recommends a “brainstorming” session to derive a reasonably complete set of exceptions for each use case. In addition to the three generic questions suggested earlier in this section, the following issues should also be explored:

  • 在此用例中是否存在某些“验证功能”发生的情况?这意味着验证函数被调用,并且可能会出现潜在的错误情况。

  • Are there cases in which some “validation function” occurs during this use case? This implies that the validation function is invoked, and a potential error condition might occur.

  • 是否存在支持功能(或参与者)无法做出适当响应的情况?例如,用户操作等待响应,但响应的函数超时。

  • Are there cases in which a supporting function (or actor) will fail to respond appropriately? For example, a user action awaits a response but the function that is to respond times out.

  • 系统性能不佳是否会导致意外或不当的用户操作?例如,基于 Web 或移动的界面响应太慢,导致用户在处理按钮上进行多次选择。这些不恰当地选择队列并最终产生错误条件。

  • Can poor system performance result in unexpected or improper user actions? For example, a Web-based or mobile interface responds too slowly, resulting in a user making multiple selects on a processing button. These selects queue inappropriately and ultimately generate an error condition.

通过询问和回答这些问题而开发的扩展列表应该使用以下标准“合理化”[Coc01b]:如果软件可以检测到所描述的条件,然后在条件发生后处理该条件,则应在用例中注明例外情况。检测到。在某些情况下,异常会促使另一个用例的开发(以处理所指出的情况)。

The list of extensions developed by asking and answering these questions should be “rationalized” [Coc01b] using the following criteria: An exception should be noted within the use case if the software can detect the condition described and then handle the condition once it has been detected. In some cases, an exception will precipitate the development of another use case (to handle the condition noted).

8.2.3 记录用例

8.2.3 Documenting Use Cases

第 8.2.2 节中介绍的非正式用例有时足以进行需求建模。然而,当用例涉及关键活动或描述具有大量异常的一组复杂步骤时,可能需要更正式的方法。

The informal use cases presented in Section 8.2.2 are sometimes sufficient for requirements modeling. However, when a use case involves a critical activity or describes a complex set of steps with a significant number of exceptions, a more formal approach may be desirable.

侧栏中显示的 ACS-DCV 用例遵循正式用例的典型轮廓上下文中的目标确定了用例的总体范围。前提条件描述了在启动用例之前已知的真实情况。触发器标识“启动用例”的事件或条件 [Coc01b] 该 场景列出了参与者所需的特定操作以及适当的系统响应。例外情况确定了在完善初步用例时未发现的情况(第 8.2.2 节)。附加标题可能包含也可能不包含,并且是不言自明的。

The ACS-DCV use case shown in the sidebar follows a typical outline for formal use cases. The goal in context identifies the overall scope of the use case. The precondition describes what is known to be true before the use case is initiated. The trigger identifies the event or condition that “gets the use case started” [Coc01b]. The scenario lists the specific actions that are required by the actor and the appropriate system responses. Exceptions identify the situations uncovered as the preliminary use case is refined (Section 8.2.2). Additional headings may or may not be included and are reasonably self-explanatory.

大多数开发人员喜欢在根据用户故事创建用例时创建图形表示。图表表示可以促进所有利益相关者更好地理解问题,特别是当场景很复杂时。正如我们在本书前面提到的,UML 提供了用例图绘制功能。图 8.2描绘了SafeHome产品的用例图。用例图有助于展示使用场景中用例之间的关系。每个用例都由一个椭圆形表示。本节仅讨论ACS-DCV用例。

Most developers like to create graphical representation as they create use cases out of user stories. A diagrammatic representation can facilitate better understanding of the problem by all stakeholders, particularly when the scenario is complex. As we noted earlier in this book, UML provides use case diagramming capability. Figure 8.2 depicts a use case diagram for the SafeHome product. The use case diagram helps to show the relations among the use cases in the usage scenario. Each use case is represented by an oval. Only the ACS-DCV use case has been discussed in this section.

8.2 SafeHome系统的初步用

Figure 8.2 Preliminary use case diagram for the SafeHome system

每个建模符号都有局限性,UML 用例也不例外。与任何其他形式的书面描述一样,用例的好坏取决于其作者。如果描述不清楚,则用例可能会产生误导或含糊不清。用例侧重于功能和行为需求,通常不适合非功能需求。对于需求模型必须具有重要细节和精度的情况(例如,安全关键系统),用例可能不够。

Each modeling notation has limitations, and the UML use case is no exception. Like any other form of written description, a use case is only as good as its author(s). If the description is unclear, the use case can be misleading or ambiguous. A use case focuses on function and behavioral requirements and is generally inappropriate for nonfunctional requirements. For situations in which the requirements model must have significant detail and precision (e.g., safety critical systems), a use case may not be sufficient.

但是,基于场景的建模适用于您作为软件工程师会遇到的绝大多数情况。如果开发得当,用例可以作为建模工具提供巨大的好处。第137页

However, scenario-based modeling is appropriate for a significant majority of all situations that you will encounter as a software engineer. If developed properly, the use case can provide substantial benefit as a modeling tool.Page 137

8.3 基于类的建模

8.3 Class-Based Modeling

如果你环顾一个房间,就会发现有一组可以轻松识别、分类和定义的物理对象(在属性和操作方面)。但是,当您“环顾”软件应用程序的问题空间时,类(和对象)可能更难以理解。

If you look around a room, there is a set of physical objects that can be easily identified, classified, and defined (in terms of attributes and operations). But when you “look around” the problem space of a software application, the classes (and objects) may be more difficult to comprehend.

8.3.1 识别分析类

8.3.1 Identifying Analysis Classes

我们可以通过检查作为需求模型的一部分开发的使用场景(第 8.2 节)并对为要构建的系统开发的用例执行“语法解析”[Abb83]来开始识别类。通过在每个名词或名词短语下划线并将其输入到一个简单的表格中来确定类别。应该注意同义词。如果需要类(名词)来实现解决方案,那么它就是解决方案空间的一部分;否则,如果类仅需要描述解决方案,那么它就是问题空间的一部分。第138页

We can begin to identify classes by examining the usage scenarios developed as part of the requirements model (Section 8.2) and performing a “grammatical parse” [Abb83] on the use cases developed for the system to be built. Classes are determined by underlining each noun or noun phrase and entering it into a simple table. Synonyms should be noted. If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space.Page 138

但是,一旦所有名词都被分离出来,我们应该寻找什么呢?分析类通过以下方式之一表现出来:

But what should we look for once all the nouns have been isolated? Analysis classes manifest themselves in one of the following ways:

  • 产生或消费供基于计算机的系统使用的信息的外部实体(例如,其他系统、设备、人员)。

  • External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system.

  • 属于问题信息域一部分的事物(例如报告、显示、字母、信号)。

  • Things (e.g., reports, displays, letters, signals) that are part of the information domain for the problem.

  • 系统操作范围内发生的事件或事件(例如,财产转移或一系列机器人运动的完成)。

  • Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation.

  • 与系统交互的人员所扮演的角色(例如,经理、工程师、销售人员)。

  • Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.

  • 与应用程序相关的组织单位(例如部门、组、团队)。

  • Organizational units (e.g., division, group, team) that are relevant to an application.

  • 确定问题背景和系统整体功能的场所(例如,生产车间或装卸码头)。

  • Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system.

  • 定义一类对象或相关对象类的结构(例如,传感器、四轮车辆或计算机)。

  • Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects.

这种分类只是文献中提出的众多分类之一。8例如,Budd [Bud96] 建议对类进行分类,其中包括数据的生产者(源)和消费者(接收器)、数据管理器视图观察者类以及辅助类

This categorization is but one of many that have been proposed in the literature.8 For example, Budd [Bud96] suggests a taxonomy of classes that includes producers (sources) and consumers (sinks) of data, data managers, view or observer classes, and helper classes.

为了说明如何在建模的早期阶段定义分析类,请考虑对SafeHome安全功能的处理叙述9进行语法分析(名词加下划线,动词斜体)。

To illustrate how analysis classes might be defined during the early stages of modeling, consider a grammatical parse (nouns are underlined, verbs italicized) for a processing narrative9 for the SafeHome security function.

SafeHome安全功能 使房主能够在安装安全系统时对其进行配置监控连接安全系统的所有传感器,并通过互联网PC控制面板与房主进行交互

The SafeHome security function enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through the Internet, a PC or a control panel.

安装过程中,SafeHome PC 用于对系统进行编程配置。每个传感器都被分配了一个号码类型密码被编程用于布防撤防系统,并且输入电话号码以便在传感器事件发生时拨打

During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.

当识别到传感器事件时,软件会调用连接到系统的声音警报。在系统配置活动期间,经过房主指定的延迟时间后,软件会拨打监控服务的电话号码,提供有关位置信息报告检测事件的性质。电话号码将每 20 秒重拨一次,直至获得电话连接

When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until telephone connection is obtained.

房主通过控制面板、PC 或浏览器(统称为界面)接收 安全信息。该界面在控制面板、PC 机或浏览器窗口上显示提示信息系统状态信息。房主互动采取以下形式。。。

The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form . . .

第139页提取名词,我们可以提出几个潜在的类别:

Page 139Extracting the nouns, we can propose several potential classes:

潜力班 一般分类
房主 角色或外部实体
传感器 外部实体
控制面板 外部实体
安装 发生
系统(别名安全系统) 事物
数量、类型 不是物体,是传感器的属性
主密码 事物
电话号码 事物
传感器事件 发生
声音警报 外部实体
监控服务 组织单位或外部实体

该列表将一直持续到处理叙述中的所有名词都被考虑为止。请注意,我们将列表中的每个条目称为“潜在”对象。在做出最终决定之前,我们必须进一步考虑。

The list would be continued until all nouns in the processing narrative have been considered. Note that we call each entry in the list a “potential” object. We must consider each further before a final decision is made.

Coad 和 Yourdon [Coa91] 建议在您考虑将每个潜在类别包含在分析模型中时应使用的六个选择特征:

Coad and Yourdon [Coa91] suggest six selection characteristics that should be used as you consider each potential class for inclusion in the analysis model:

  1. 保留信息。仅当必须记住有关潜在类的信息以便系统能够运行时,潜在类才会在分析过程中有用。

  2. Retained information. The potential class will be useful during analysis only if information about it must be remembered so that the system can function.

  3. 需要的服务。潜在类必须具有一组可识别的操作,这些操作可以以某种方式更改其属性的值。

  4. Needed services. The potential class must have a set of identifiable operations that can change the value of its attributes in some way.

  5. 多种属性。需求分析时,重点关注“主要”信息;事实上,具有单个属性的类在设计期间可能很有用,但在分析活动期间可能更好地表示为另一个类的属性。

  6. Multiple attributes. During requirement analysis, the focus should be on “major” information; a class with a single attribute may, in fact, be useful during design but is probably better represented as an attribute of another class during the analysis activity.

  7. 共同属性。可以为潜在类定义一组属性,这些属性适用于该类的所有实例。

  8. Common attributes. A set of attributes can be defined for the potential class, and these attributes apply to all instances of the class.

  9. 常见操作。可以为潜在类定义一组操作,这些操作适用于该类的所有实例。

  10. Common operations. A set of operations can be defined for the potential class, and these operations apply to all instances of the class.

  11. 基本要求。出现在问题空间中并产生或消耗对系统任何解决方案的操作至关重要的信息的外部实体几乎总是被定义为需求模型中的类。

  12. Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements model.

要被视为包含在需求模型中的合法类,潜在对象应该满足大多数这些特征。在分析模型中包含潜在类的决定有些主观,以后的评估可能会导致对象被丢弃或恢复。然而,基于类的建模的第一步是类的定义,并且必须做出决策(甚至是主观的决策)。您应该将选择特征应用于潜在SafeHome类的列表:第 140 页

To be considered a legitimate class for inclusion in the requirements model, a potential object should satisfy most of these characteristics. The decision for inclusion of potential classes in the analysis model is somewhat subjective, and later evaluation may cause an object to be discarded or reinstated. However, the first step of class-based modeling is the definition of classes, and decisions (even subjective ones) must be made. You should apply the selection characteristics to the list of potential SafeHome classes:Page 140

潜力班 适用的特征数
房主 被拒绝:1、2 失败,尽管 6 申请
传感器 接受:全部适用
控制面板 接受:全部适用
安装 拒绝
系统(别名安全功能) 接受:全部适用
数量、类型 被拒绝:3 次失败,传感器属性
主密码 拒绝:3 次失败
电话号码 拒绝:3 次失败
传感器事件 接受:全部适用
声音警报 已接受: 2, 3, 4, 5, 6 申请
监控服务 被拒绝:1、2 失败,尽管 6 申请

需要注意的是: (1) 上述列表并未包含所有内容,因此必须添加额外的类来完成模型;(2) 一些被拒绝的潜在类别将成为那些被接受的类别的属性(例如,数量和类型是传感器的属性,主密码和电话号码可能成为系统的属性);(3) 对问题的不同陈述可能会导致做出不同的“接受或拒绝”决定(例如,如果每个房主都有单独的密码或通过声纹识别,则房主类别将满足特征 1 和 2,并且具有已被接受)。

It should be noted that: (1) the preceding list is not all-inclusive, so additional classes would have to be added to complete the model; (2) some of the rejected potential classes will become attributes for those classes that were accepted (e.g., number and type are attributes of Sensor, and master password and telephone number may become attributes of System); and (3) different statements of the problem might cause different “accept or reject” decisions to be made (e.g., if each homeowner had an individual password or was identified by voice print, the Homeowner class would satisfy characteristics 1 and 2 and would have been accepted).

8.3.2 定义属性和操作

8.3.2 Defining Attributes and Operations

属性描述已选择包含在分析模型中的类。定义类的属性是澄清类在问题空间上下文中的含义的。

Attributes describe a class that has been selected for inclusion in the analysis model. It is the attributes that define the class—that clarify what is meant by the class in the context of the problem space.

要为分析类开发一组有意义的属性,您应该研究每个用例并选择那些合理“属于”该类的“事物”。此外,应针对每个类别回答以下问题:哪些数据项(复合和/或基本)在当前问题的上下文中完全定义了该类别?

To develop a meaningful set of attributes for an analysis class, you should study each use case and select those “things” that reasonably “belong” to the class. In addition, the following question should be answered for each class: What data items (composite and/or elementary) fully define this class in the context of the problem at hand?

为了说明这一点,我们考虑为 SafeHome 定义的System类房主可以配置安全功能以反映传感器信息、警报响应信息、激活和停用信息、识别信息等。我们可以用以下方式表示这些复合数据项:

To illustrate, we consider the System class defined for SafeHome. A homeowner can configure the security function to reflect sensor information, alarm response information, activation and deactivation information, identification information, and so forth. We can represent these composite data items in the following manner:

身份信息=系统ID+验证电话+系统状态

identification information = system ID + verification phone number + system status

报警响应信息=延迟时间+电话号码

alarm response information = delay time + telephone number

激活/停用信息=主密码+允许尝试次数+临时密码

activation/deactivation information = master password + number of allowable tries + temporary password

第 141 页等号右侧的每个数据项都可以进一步定义为基本级别,但出于我们的目的,它们构成了System类的合理属性列表(图 8.3)。

Page 141Each of the data items to the right of the equal sign could be further defined to an elementary level, but for our purposes, they constitute a reasonable list of attributes for the System class (Figure 8.3).

图8.3 System 类的类

Figure 8.3 Class diagram for the System class

传感器是整个SafeHome系统的一部分,但它们并未在图 8.3中列为数据项或属性。Sensor已被定义为一个类,并且多个Sensor对象将与System类关联。一般来说,如果多个项目与该类相关联,我们会避免将一项定义为属性。

Sensors are part of the overall SafeHome system, and yet they are not listed as data items or as attributes in Figure 8.3. Sensor has already been defined as a class, and multiple Sensor objects will be associated with the System class. In general, we avoid defining an item as an attribute if more than one of the items is to be associated with the class.

操作定义了对象的行为。尽管存在许多不同类型的操作,但它们通常可分为四大类:(1) 以某种方式操纵数据的操作(例如,添加、删除、重新格式化、选择),(2) 执行计算的操作,( 3) 查询对象状态的操作,以及 (4) 监视对象是否发生控制事件的操作。这些功能是通过对属性和/或关联进行操作来完成的(第 8.3.3 节)。因此,操作必须“了解”类属性和关联的性质。

Operations define the behavior of an object. Although many different types of operations exist, they can generally be divided into four broad categories: (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting), (2) operations that perform a computation, (3) operations that inquire about the state of an object, and (4) operations that monitor an object for the occurrence of a controlling event. These functions are accomplished by operating on attributes and/or associations (Section 8.3.3). Therefore, an operation must have “knowledge” of the nature of the class attributes and associations.

8.3.3 UML类模型

8.3.3 UML Class Models

作为为分析类派生一组操作的第一次迭代,您可以再次研究处理叙述(或用例)并选择合理属于该类的那些操作。为了实现这一点,需要再次研究语法分析,并分离动词。其中一些动词是合法的操作,可以很容易地连接到特定的类。例如,从本章前面介绍的SafeHome处理叙述中,我们看到“传感器被分配了编号和类型”或“主密码被编程用于布防和撤防系统”。这些短语表明了几件事:第142页

As a first iteration at deriving a set of operations for an analysis class, you can again study a processing narrative (or use case) and select those operations that reasonably belong to the class. To accomplish this, the grammatical parse is again studied, and verbs are isolated. Some of these verbs will be legitimate operations and can be easily connected to a specific class. For example, from the SafeHome processing narrative presented earlier in this chapter, we see that “sensor is assigned a number and type” or “a master password is programmed for arming and disarming the system.” These phrases indicate several things:Page 142

  • 分配()操作与传感器类相关。

  • That an assign() operation is relevant for the Sensor class.

  • program ()操作将应用于System类。

  • That a program() operation will be applied to the System class.

  • arm ()disarm()是适用于System类的操作。

  • That arm() and disarm() are operations that apply to System class.

第143页经过进一步调查,操作program()很可能会被划分为配置系统所需的几个更具体的子操作。例如,program()意味着指定电话号码、配置系统特性(例如,创建传感器表、输入警报特性)以及输入密码。但现在,我们将program()指定为单个操作。

Page 143Upon further investigation, it is likely that the operation program() will be divided into several more specific suboperations required to configure the system. For example, program() implies specifying phone numbers, configuring system characteristics (e.g., creating the sensor table, entering alarm characteristics), and entering password(s). But for now, we specify program() as a single operation.

除了语法解析之外,您还可以通过考虑对象之间发生的通信来深入了解其他操作。对象通过相互传递消息来进行通信。在继续讨论操作规范之前,我们先更详细地探讨这个问题。

In addition to the grammatical parse, you can gain additional insight into other operations by considering the communication that occurs between objects. Objects communicate by passing messages to one another. Before continuing with the specification of operations, we explore this matter in a bit more detail.

第 144 页在许多情况下,两个分析类以某种方式彼此相关。在 UML 中,这些关系称为关联。参考图 8.4FloorPlan类是通过识别FloorPlan与其他两个类(Camera和Wall)之间的一组关联来定义的Wall类与允许构造墙的三个类相关联:WallSegment、WindowDoor。

Page 144In many instances, two analysis classes are related to one another in some fashion. In UML, these relationships are called associations. Referring to Figure 8.4, the FloorPlan class is defined by identifying a set of associations between FloorPlan and two other classes, Camera and Wall. The class Wall is associated with three classes that allow a wall to be constructed, WallSegment, Window, and Door.

8.4 FloorPlan 的类图(参见边栏讨论)

Figure 8.4 Class diagram for FloorPlan (see sidebar discussion)

8.3.4 类-责任-协作者建模

8.3.4 Class-Responsibility-Collaborator Modeling

类-责任-协作者 (CRC) 建模[Wir90] 提供了一种简单的方法来识别和组织与系统或产品需求相关的类。CRC 模型可以被视为索引卡的集合。每张索引卡左侧包含一份职责列表,右侧包含能够履行职责的相应协作(图 8.5)。职责是与类相关的属性和操作。协作者是那些为类提供完成职责所需的信息或操作的类。FloorPlan类的简单 CRC 索引卡如图 8.5所示。

Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. A CRC model can be viewed as a collection of index cards. Each index card contains a list of responsibilities on the left side and the corresponding collaborations that enable the responsibilities to be fulfilled on the right side (Figure 8.5). Responsibilities are the attributes and operations that are relevant for the class. Collaborators are those classes that provide a class with the information needed or action required to complete a responsibility. A simple CRC index card for the FloorPlan class is illustrated in Figure 8.5.

图8.5 CRC 模型索引卡

Figure 8.5 A CRC model index card

CRC 卡上显示的职责清单是初步的,可能会进行补充或修改。Wall 类Camera类在需要它们协作的职责旁边注明。

The list of responsibilities shown on the CRC card is preliminary and is subject to additions or modification. The classes Wall and Camera are noted next to the responsibility that requires their collaboration.

课程。识别类和对象的基本准则已在前面的8.3.1 节中介绍过。

Classes. Basic guidelines for identifying classes and objects were presented earlier in Section 8.3.1.

责任。第 8.3.2 节介绍了识别职责(属性和操作)的基本准则。

Responsibilities. Basic guidelines for identifying responsibilities (attributes and operations) were presented in Section 8.3.2.

合作。类通过以下两种方式之一履行其职责:(1) 类可以使用自己的操作来操作自己的属性,从而履行自己的职责,或者 (2) 类可以与其他类协作。通过确定一个类是否能够自行履行每项职责来确定协作。如果不能,那么它需要与另一个类交互。第 145 页

Collaborations. Classes fulfill their responsibilities in one of two ways: (1) A class can use its own operations to manipulate its own attributes, thereby fulfilling a responsibility itself, or (2) a class can collaborate with other classes. Collaborations are identified by determining whether a class can fulfill each responsibility itself. If it cannot, then it needs to interact with another class.Page 145

例如,考虑SafeHome安全功能。作为激活过程的一部分,ControlPanel对象必须确定是否有任何传感器打开。定义了名为确定传感器状态()的职责。如果传感器打开,ControlPanel必须将状态属性设置为“未就绪”。可以从每个Sensor对象获取传感器信息。仅当ControlPanel与 Sensor 协同工作时,才能履行确定传感器状态()的职责

As an example, consider the SafeHome security function. As part of the activation procedure, the ControlPanel object must determine whether any sensors are open. A responsibility named determine-sensor-status() is defined. If sensors are open, ControlPanel must set a status attribute to “not ready.” Sensor information can be acquired from each Sensor object. The responsibility determine-sensor-status() can be fulfilled only if ControlPanel works in collaboration with Sensor.

一旦开发出完整的 CRC 模型,利益相关者的代表就可以使用以下方法审查该模型 [Amb95]:

Once a complete CRC model has been developed, the representatives from the stakeholders can review the model using the following approach [Amb95]:

  1. 所有参与(CRC 模型)审查的参与者都会获得 CRC 模型索引卡的子集。任何审阅者都不应该拥有两张协作的卡片。

  2. All participants in the review (of the CRC model) are given a subset of the CRC model index cards. No reviewer should have two cards that collaborate.

  3. 评审负责人仔细阅读用例。当评审领导者到达一个命名对象时,她将一个令牌传递给持有相应班级索引卡的人。

  4. The review leader reads the use case deliberately. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card.

  5. 当令牌被传递时,班级卡的持有者被要求描述卡上注明的职责。该小组确定一项(或多项)职责是否满足用例要求。

  6. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use case requirement.

  7. 如果发现错误,将对卡片进行修改。这可能包括新类别的定义(以及相应的 CRC 索引卡)或修改现有卡上的责任或协作列表。

  8. If an error is found, modifications are made to the cards. This may include the definition of new classes (and corresponding CRC index cards) or revising lists of responsibilities or collaborations on existing cards.

8.4 功能建模

8.4 Functional Modeling

功能模型涉及两个应用程序处理元素,每个元素代表不同的过程抽象级别:(1) 应用程序向最终用户提供的用户可观察的功能,以及 (2) 分析类中包含的操作,这些操作实现与班上。

The functional model addresses two application processing elements, each representing a different level of procedural abstraction: (1) user-observable functionality that is delivered by the app to end users, and (2) the operations contained within analysis classes that implement behaviors associated with the class.

用户可观察的功能包括由用户直接启动的任何处理功能。例如,金融移动应用程序可能会实现各种金融功能(例如,抵押贷款付款的计算)。这些函数可以使用分析类中的操作来实现,但从最终用户的角度来看,函数(更准确地说,函数提供的数据)是可见的结果。

User-observable functionality encompasses any processing functions that are initiated directly by the user. For example, a financial mobile app might implement a variety of financial functions (e.g., computation of mortgage payment). These functions may be implemented using operations within analysis classes, but from the point of view of the end user, the function (more correctly, the data provided by the function) is the visible outcome.

在过程抽象的较低级别,需求模型描述了分析类操作要执行的处理。这些操作操纵类属性,并在类相互协作以完成某些所需行为时涉及。

At a lower level of procedural abstraction, the requirements model describes the processing to be performed by analysis class operations. These operations manipulate class attributes and are involved as classes collaborate with one another to accomplish some required behavior.

8.4.1 程序视图

8.4.1 A Procedural View

无论过程抽象的级别如何,UML 活动图都可以用来表示处理细节。在分析层面,只有在功能相对复杂的情况下才应该使用活动图。移动应用程序的大部分复杂性并不在于所提供的功能,而是在于可访问信息的性质以及可操纵信息的方式。

Regardless of the level of procedural abstraction, the UML activity diagram can be used to represent processing details. At the analysis level, activity diagrams should be used only where the functionality is relatively complex. Much of the complexity of mobile apps occurs not in the functionality provided, but rather with the nature of the information that can be accessed and the ways in which this can be manipulated.

第 147 页UML 活动图通过提供特定场景中交互流程的图形表示来补充用例。活动图就像流程图。活动图(图 8.6)使用圆角矩形表示特定的系统功能,使用箭头表示系统的流程,决策菱形表示分支决策(从菱形发出的每个箭头都被标记),并使用水平实线表示并行活动正在发生。

Page 147The UML activity diagram supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario. An activity diagram is like a flowchart. The activity diagram (Figure 8.6) uses rounded rectangles to imply a specific system function, arrows to represent flow through the system, decision diamonds to depict a branching decision (each arrow emanating from the diamond is labeled), and solid horizontal lines to indicate that parallel activities are occurring.

8.6 takeControlOf Camera ( )操作的活动图

Figure 8.6 Activity diagram for the takeControlOf Camera() operation

SafeHomeAssured.com相对复杂的功能示例通过标题为“获取我的空间传感器布局的建议”的用例来解决。用户已经为要监控的空间开发了布局,在此用例中,选择该布局并请求布局内传感器的推荐位置。SafeHomeAssured.com以布局的图形表示形式进行响应,并提供有关传感器推荐位置的附加信息。交互非常简单,内容稍微复杂一些,但底层功能非常复杂。该系统必须对地板布局进行相对复杂的分析,以确定最佳的传感器组。它必须检查房间尺寸和门窗位置,并将这些与传感器功能和规格相协调。任务可不小!可以使用一组活动图来描述此用例的处理。

An example of a relatively complex functionality for SafeHomeAssured.com is addressed by a use case entitled Get recommendations for sensor layout for my space. The user has already developed a layout for the space to be monitored, and in this use case, selects that layout and requests recommended locations for sensors within the layout. SafeHomeAssured.com responds with a graphical representation of the layout with additional information on the recommended locations for sensors. The interaction is quite simple and the content is somewhat more complex, but the underlying functionality is very sophisticated. The system must undertake a relatively complex analysis of the floor layout to determine the optimal set of sensors. It must examine room dimensions and the location of doors and windows and coordinate these with sensor capabilities and specifications. No small task! A set of activity diagrams can be used to describe processing for this use case.

第二个示例是用例控制摄像机。在此用例中,交互相对简单,但有可能实现复杂的功能,因为这种“简单”操作需要与远程且可通过互联网访问的设备进行复杂的通信。另一个可能的复杂情况涉及当多个授权人员试图同时监视和/或控制单个传感器时的控制协商。第148页

The second example is the use case Control cameras. In this use case, the interaction is relatively simple, but there is the potential for complex functionality, given that this “simple” operation requires complex communication with devices located remotely and accessible across the Internet. A further possible complication relates to negotiation of control when multiple authorized people attempt to monitor and/or control a single sensor at the same time.Page 148

图 8.6描述了takeControlOfCamera()操作的活动图,该操作是控制相机用例中使用的相机分析类的一部分。应该注意的是,程序流程中还调用了两个附加操作:requestCameraLock()(尝试锁定该用户的相机)和getCurrentCameraUser()(检索当前控制相机的用户的名称)。在软件设计开始之前,不会考虑指示如何调用这些操作的构造细节以及每个操作的接口细节。

Figure 8.6 depicts an activity diagram for the takeControlOfCamera() operation that is part of the Camera analysis class used within the Control cameras use case. It should be noted that two additional operations are invoked with the procedural flow: requestCameraLock(), which tries to lock the camera for this user, and getCurrentCameraUser(), which retrieves the name of the user who is currently controlling the camera. The construction details indicating how these operations are invoked and the interface details for each operation are not considered until software design commences.

8.4.2 UML序列图

8.4.2 UML Sequence Diagrams

UML序列图可用于行为建模。序列图还可用于显示事件如何导致对象之间的转换。一旦通过检查用例识别了事件,建模者就会创建一个序列图——表示事件如何导致从一个对象流到另一个对象作为时间的函数。序列图是用例的简写版本。它代表关键类和导致行为在类之间流动的事件。

The UML sequence diagram can be used for behavioral modeling. Sequence diagrams can also be used to show how events cause transitions from object to object. Once events have been identified by examining a use case, the modeler creates a sequence diagram—a representation of how events cause flow from one object to another as a function of time. The sequence diagram is a shorthand version of the use case. It represents key classes and the events that cause behavior to flow from class to class.

图 8.7展示了SafeHome安全功能的部分序列图。每个箭头代表一个事件(源自用例)并指示事件如何在SafeHome对象之间传递行为。时间是垂直(向下)测量的,狭窄的垂直矩形表示处理活动所花费的时间。状态可以沿着垂直时间线显示。

Figure 8.7 illustrates a partial sequence diagram for the SafeHome security function. Each of the arrows represents an event (derived from a use case) and indicates how the event channels behavior between SafeHome objects. Time is measured vertically (downward), and the narrow vertical rectangles represent time spent in processing an activity. States may be shown along a vertical time line.

8.7 SafeHome安全功能的时序图部分)

Figure 8.7 Sequence diagram (partial) for the SafeHome security function

第 149 页第一个事件“系统就绪”源自外部环境,并将行为传递给Homeowner对象。房主输入密码。请求查找事件被传递到系统,系统在简单的数据库中查找密码并将结果找到或未找到)返回到控制面板(现在处于比较状态)。有效的密码会向系统发出密码=正确事件,系统会通过请求激活事件激活传感器最终,通过激活成功事件,控制权将传递回房主。

Page 149The first event, system ready, is derived from the external environment and channels behavior to the Homeowner object. The homeowner enters a password. A request lookup event is passed to System, which looks up the password in a simple database and returns a result (found or not found) to ControlPanel (now in the comparing state). A valid password results in a password=correct event to System, which activates Sensors with a request activation event. Ultimately, control is passed back to the homeowner with the activation successful event.

一旦开发出完整的序列图,所有导致系统对象之间转换的事件都可以整理成一组输入事件和输出事件(来自对象)。此信息对于为要构建的系统创建有效的设计非常有用。

Once a complete sequence diagram has been developed, all the events that cause transitions between system objects can be collated into a set of input events and output events (from an object). This information is useful in the creation of an effective design for the system to be built.

8.5 行为建模

8.5 Behavioral Modeling

行为模型表明软件将如何响应内部或外部事件或刺激。此信息对于为要构建的系统创建有效的设计非常有用。UML 活动图可用于对系统元素如何响应内部事件进行建模。UML 状态图可用于对系统元素如何响应外部事件进行建模。

A behavioral model indicates how software will respond to internal or external events or stimuli. This information is useful in the creation of an effective design for the system to be built. UML activity diagrams can be used to model how system elements respond to internal events. UML state diagrams can be used to model how system elements respond to external events.

要创建模型,您应该执行以下步骤:(1) 评估所有用例以充分了解系统内的交互序列,(2) 识别驱动交互序列的事件并了解这些事件如何与特定对象相关, (3) 为每个用例创建一个序列,(4) 构建系统的状态图,(5) 检查行为模型以验证准确性和一致性。以下各节将讨论每个步骤。

To create the model, you should perform the following steps: (1) evaluate all use cases to fully understand the sequence of interaction within the system, (2) identify events that drive the interaction sequence and understand how these events relate to specific objects, (3) create a sequence for each use case, (4) build a state diagram for the system, and (5) review the behavioral model to verify accuracy and consistency. Each of these steps is discussed in the sections that follow.

8.5.1 通过用例识别事件

8.5.1 Identifying Events with the Use Case

第 8.3.3 节中,您了解到用例表示涉及参与者和系统的一系列活动。一般来说,只要系统和参与者交换信息,就会发生事件。事件不是交换的信息,而是已交换信息的事实。

In Section 8.3.3, you learned that the use case represents a sequence of activities that involves actors and the system. In general, an event occurs whenever the system and an actor exchange information. An event is not the information that has been exchanged, but rather the fact that information has been exchanged.

检查用例的信息交换点。为了说明这一点,请重新考虑SafeHome安全功能的一部分的用例。

A use case is examined for points of information exchange. To illustrate, reconsider the use case for a portion of the SafeHome security function.

房主使用键盘输入四位数的密码。该密码将与系统中存储的有效密码进行比较。如果密码不正确,控制面板将发出一声蜂鸣声并自行重置以进行其他输入。如果密码正确,控制面板等待进一步操作。

The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

用例场景的下划线部分表示事件。应为每个事件确定一名参与者;应记录所交换的信息,并应列出任何条件或限制。

The underlined portions of the use case scenario indicate events. An actor should be identified for each event; the information that is exchanged should be noted, and any conditions or constraints should be listed.

作为典型事件的示例,请考虑带下划线的用例短语“房主使用键盘输入四位数密码”。在需求模型的上下文中,对象Homeowner 10将事件传输到对象ControlPanel。该事件可能称为输入密码。传输的信息是构成密码的四位数字,但这不是行为模型的重要组成部分。值得注意的是,一些事件对用例的控制流有显着的影响,而另一些事件对控制流没有直接影响。例如,输入的事件密码不会显式改变用例的控制流程,但事件密码比较的结果(源自交互“密码与系统中存储的有效密码进行比较”)将具有对SafeHome软件的信息和控制流产生显着影响。第 150 页

As an example of a typical event, consider the underlined use case phrase “homeowner uses the keypad to key in a four-digit password.” In the context of the requirements model, the object, Homeowner,10 transmits an event to the object ControlPanel. The event might be called password entered. The information transferred is the four digits that constitute the password, but this is not an essential part of the behavioral model. It is important to note that some events have an explicit impact on the flow of control of the use case, while others have no direct impact on the flow of control. For example, the event password entered does not explicitly change the flow of control of the use case, but the results of the event password compared (derived from the interaction “password is compared with the valid password stored in the system”) will have an explicit impact on the information and control flow of the SafeHome software.Page 150

一旦所有事件都被识别出来,它们就会被分配给所涉及的对象。对象可以负责生成事件(例如,Homeowner生成密码输入事件)或识别其他地方发生的事件(例如,ControlPanel识别密码比较事件的二进制结果)。

Once all events have been identified, they are allocated to the objects involved. Objects can be responsible for generating events (e.g., Homeowner generates the password entered event) or recognizing events that have occurred elsewhere (e.g., ControlPanel recognizes the binary result of the password compared event).

8.5.2 UML状态图

8.5.2 UML State Diagrams

在行为建模的背景下,必须考虑状态的两种不同特征:(1)系统执行其功能时每个类的状态;(2)系统执行其功能时从外部观察到的系统状态。

In the context of behavioral modeling, two different characterizations of states must be considered: (1) the state of each class as the system performs its function and (2) the state of the system as observed from the outside as the system performs its function.

类的状态具有被动和主动特征[Cha93]。被动状态只是分配给对象属性的当前值。对象的活动状态指示对象在经历持续转换或处理时的状态。必须发生一个事件(有时称为触发器)来强制对象从一种活动状态转换到另一种活动状态。

The state of a class takes on both passive and active characteristics [Cha93]. A passive state is simply the current values assigned to an object’s attributes. The active state of an object indicates the status of the object as it undergoes a continuing transformation or processing. An event (sometimes called a trigger) must occur to force an object to make a transition from one active state to another.

分析类的状态图。行为模型的一个组成部分是UML状态图11,其表示每个类的活动状态以及引起这些活动状态之间的变化的事件(触发器)。图 8.8展示了SafeHome安全功能中ControlPanel对象的状态图。

State Diagrams for Analysis Classes. One component of a behavioral model is a UML state diagram11 that represents active states for each class and the events (triggers) that cause changes between these active states. Figure 8.8 illustrates a state diagram for the ControlPanel object in the SafeHome security function.

8.8 ControlPanel 类的状态

Figure 8.8 State diagram for the ControlPanel class

图 8.8中显示的每个箭头表示对象从一种活动状态到另一种活动状态的转换。每个箭头显示的标签代表触发转换的事件。尽管活动状态模型提供了对对象“生命历史”的有用洞察,但可以指定附加信息以更深入地理解对象的行为。除了指定导致转换发生的事件之外,您还可以指定一个防护和一个操作 [Cha93]。防护是一个布尔条件,必须满足该条件才能发生转换。例如,图 8.8中从“读取”状态到“比较”状态转换的保护可以通过检查用例来确定:

Each arrow shown in Figure 8.8 represents a transition from one active state of an object to another. The labels shown for each arrow represent the event that triggers the transition. Although the active state model provides useful insight into the “life history” of an object, it is possible to specify additional information to provide more depth in understanding the behavior of an object. In addition to specifying the event that causes the transition to occur, you can specify a guard and an action [Cha93]. A guard is a Boolean condition that must be satisfied for the transition to occur. For example, the guard for the transition from the “reading” state to the “comparing” state in Figure 8.8 can be determined by examining the use case:

if(密码输入 = 4 位数字)则与存储的密码进行比较

if (password input = 4 digits) then compare to stored password

一般来说,转换的保护通常取决于对象的一个​​或多个属性的值。换句话说,防护依赖于对象的被动状态。第 151 页

In general, the guard for a transition usually depends upon the value of one or more attributes of an object. In other words, the guard depends on the passive state of the object.Page 151

动作与状态转换同时发生或因状态转换而发生,并且通常涉及对象的一个​​或多个操作(责任)例如,连接到密码输入事件的操作(图 8.8)是一个名为validatePassword()的操作,它访问密码对象并执行逐位比较以验证输入的密码。

An action occurs concurrently with the state transition or because of it and generally involves one or more operations (responsibilities) of the object. For example, the action connected to the password entered event (Figure 8.8) is an operation named validatePassword() that accesses a password object and performs a digit-by-digit comparison to validate the entered password.

8.5.3 UML活动图

8.5.3 UML Activity Diagrams

UML 活动图通过提供特定场景中交互流程的图形表示来补充用例。许多软件工程师喜欢将活动图描述为表示系统如何对内部事件做出反应的方式。

The UML activity diagram supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario. Many software engineers like to describe activity diagrams as a way of representing how a system reacts to internal events.

ACS-DCV用例的活动图如图 8.9所示。应该注意的是,活动图添加了用例未直接提及(但暗示)的附加细节。例如,用户只能尝试输入用户ID密码有限次数。决策菱形表示如下:“提示重新进入。”

An activity diagram for the ACS-DCV use case is shown in Figure 8.9. It should be noted that the activity diagram adds additional detail not directly mentioned (but implied) by the use case. For example, a user may only attempt to enter userID and password a limited number of times. A decision diamond represents this below: “Prompt for reentry.”

8.9 通过互联网访问摄像机监控——显示摄像机视图功能活动

Figure 8.9 Activity diagram for Access camera surveillance via the Internet—display camera views function

UML 泳道图是活动图的一个有用变体,它允许您表示用例描述的活动流,同时指示哪个参与者(如果特定用例中涉及多个参与者)或分析类(第 8.3.1 节)负责活动矩形描述的操作。职责被表示为垂直划分图表的平行线段,就像游泳池中的泳道一样。

The UML swimlane diagram is a useful variation of the activity diagram and allows you to represent the flow of activities described by the use case and at the same time indicate which actor (if there are multiple actors involved in a specific use case) or analysis class (Section 8.3.1) has responsibility for the action described by an activity rectangle. Responsibilities are represented as parallel segments that divide the diagram vertically, like the lanes in a swimming pool.

第153页三个分析类——Homeowner、CameraInterface——在图 8.9所示的活动图的上下文中具有直接或间接的职责。参考图8.10,活动图被重新排列,以便与分析类相关的活动落入该类的泳道内。例如,Interface类表示房主所看到的用户界面。活动图指出了界面负责的两个提示——“提示重新进入”和“提示另一个视图”。这些提示和与之相关的决策属于界面泳道。然而,箭头从该泳道引回房主泳道,房主操作发生在该泳道中。

Page 153Three analysis classes—Homeowner, Camera, and Interface—have direct or indirect responsibilities in the context of the activity diagram represented in Figure 8.9. Referring to Figure 8.10, the activity diagram is rearranged so that activities associated with an analysis class fall inside the swimlane for that class. For example, the Interface class represents the user interface as seen by the homeowner. The activity diagram notes two prompts that are the responsibility of the interface—“prompt for reentry” and “prompt for another view.” These prompts and the decisions associated with them fall within the Interface swimlane. However, arrows lead from that swimlane back to the Homeowner swimlane, where homeowner actions occur.

图8.10 通过互联网访问摄像机监控泳道图——显示摄像机视图功能

Figure 8.10 Swimlane diagram for Access camera surveillance via the Internet—display camera views function

第154页用例以及活动图和泳道图都是面向程序的。总的来说,它们可用于表示各种参与者调用特定功能(或其他过程步骤)以满足系统要求的方式。

Page 154Use cases, along with the activity and swimlane diagrams, are procedurally oriented. Taken together they can be used to represent the way various actors invoke specific functions (or other procedural steps) to meet the requirements of the system.

8.6 总结

8.6 Summary

需求建模的目标是创建各种表示形式来描述客户的需求,为创建软件设计奠定基础,并定义一组在软件构建后即可验证的需求。需求模型弥补了描述整个系统和业务功能的系统级描述与描述软件的应用程序体系结构、用户界面和组件级结构的软件设计之间的差距。

The objective of requirements modeling is to create a variety of representations that describe what the customer requires, establish a basis for the creation of a software design, and define a set of requirements that can be validated once the software is built. The requirements model bridges the gap between a system-level description that describes overall system and business functionality and a software design that describes the software’s application architecture, user interface, and component-level structure.

基于场景的模型从用户的角度描述软件需求。用例——参与者和软件之间交互的叙述或模板驱动的描述——是主要的建模元素。用例是在需求获取过程中得出的,定义了特定功能或交互的关键步骤。用例的正式程度和细节程度各不相同,但它们可以为所有其他分析建模活动提供必要的输入。场景还可以使用活动图来描述,活动图是描述特定场景内处理流程的图形表示。用例中的时间关系可以使用序列图进行建模。

Scenario-based models depict software requirements from the user’s point of view. The use case—a narrative or template-driven description of an interaction between an actor and the software—is the primary modeling element. Derived during requirements elicitation, the use case defines the key steps for a specific function or interaction. The degree of use case formality and detail varies, but they can provide necessary input to all other analysis modeling activities. Scenarios can also be described using an activity diagram—a graphical representation that depicts the processing flow within a specific scenario. Temporal relations in a use case can be modeled using sequence diagrams.

基于类的建模使用从用例和其他书面应用程序描述中派生的信息来识别分析类。语法解析可用于从基于文本的叙述中提取候选类、属性和操作。类的定义标准是使用解析结果来定义的。

Class-based modeling uses information derived from use cases and other written application descriptions to identify analysis classes. A grammatical parse may be used to extract candidate classes, attributes, and operations from text-based narratives. Criteria for the definition of a class are defined using the parse results.

一组类-责任-协作者索引卡可用于定义类之间的关系。此外,可以应用各种 UML 建模符号来定义类之间的层次结构、关系、关联、聚合和依赖关系。

A set of class-responsibility-collaborator index cards can be used to define relationships between classes. In addition, a variety of UML modeling notation can be applied to define hierarchies, relationships, associations, aggregations, and dependencies among classes.

需求分析期间的行为建模描述了软件的动态行为。行为模型使用来自基于场景或基于类的元素的输入来表示分析类的状态。为了实现这一点,需要识别状态,定义导致类(或系统)从一种状态转换到另一种状态的事件,并且还识别完成转换时发生的操作。UML 状态图、活动图、泳道图和序列图可用于行为建模。

Behavioral modeling during requirements analysis depicts dynamic behavior of the software. The behavioral model uses input from scenario-based or class-based elements to represent the states of analysis classes. To accomplish this, states are identified, the events that cause a class (or the system) to make a transition from one state to another are defined, and the actions that occur as transition is accomplished are also identified. UML state diagrams, activity diagrams, swim lane diagrams, and sequence diagrams can be used for behavioral modeling.

第155页

Page 155

问题与思考点

Problems and Points to Ponder

8.1. 创建需求模型后是否可以立即开始编码?解释你的答案,然后提出反驳。

8.1. Is it possible to begin coding immediately after a requirements model has been created? Explain your answer, and then argue the counterpoint.

8.2. 分析的经验法则是模型“应该关注问题或业务领域中可见的需求”。哪些类型的需求在这些领域中可见?举几个例子。

8.2. An analysis rule of thumb is that the model “should focus on requirements that are visible within the problem or business domain.” What types of requirements are not visible in these domains? Provide a few examples.

8.3. 一个大城市的公共工程部门决定开发一个基于网络的坑洞跟踪和修复系统(PHTRS)。描述如下:

8.3. The department of public works for a large city has decided to develop a Web-based pothole tracking and repair system (PHTRS). A description follows:

公民可以登录网站并报告坑洼的位置和严重程度。据报道,坑洼被记录在“公共工程部门维修系统”中,并被分配一个识别号码,按街道地址、大小(范围为 1 到 10)、位置(中间、路边等)、区域存储(根据街道地址确定)和修复优先级(根据坑洞的大小确定)。工单数据与每个坑洞相关联,包括坑洞位置和大小、维修人员识别号、人员数量、分配的设备、修复所需时间、孔状态(正在进行中、已修复、临时修复、未修复)、使用的填充材料数量以及维修成本(根据使用的时间、人数、使用的材料和设备计算)。最后,创建一个损坏文件来保存有关坑洼造成的报告损坏的信息,包括公民的姓名、地址、电话号码、损坏类型和损坏金额。PHTRS 是一个在线系统;所有查询都将以交互方式进行。

Citizens can log onto a website and report the location and severity of potholes. As potholes are reported they are logged within a “public works department repair system” and are assigned an identifying number, stored by street address, size (on a scale of 1 to 10), location (middle, curb, etc.), district (determined from street address), and repair priority (determined from the size of the pothole). Work order data are associated with each pothole and include pothole location and size, repair crew identifying number, number of people on crew, equipment assigned, hours applied to repair, hole status (work in progress, repaired, temporary repair, not repaired), amount of filler material used, and cost of repair (computed from hours applied, number of people, material and equipment used). Finally, a damage file is created to hold information about reported damage due to the pothole and includes citizen’s name, address, phone number, type of damage, and dollar amount of damage. PHTRS is an online system; all queries are to be made interactively.

绘制 PHTRS 系统的 UML 用例图。您必须对用户与该系统交互的方式做出一些假设。

Draw a UML use case diagram PHTRS system. You’ll have to make a number of assumptions about the manner in which a user interacts with this system.

8.4. 编写两个或三个用例来描述问题 8.3中描述的 PHTRS 中各个参与者的角色。

8.4. Write two or three use cases that describe the roles of various actors in the PHTRS described in Problem 8.3.

8.5。为 PHTRS 的一个方面制定活动图。

8.5. Develop an activity diagram for one aspect of PHTRS.

8.6。为 PHTRS 的一个或多个方面制定泳道图。

8.6. Develop a swimlane diagram for one or more aspects of PHTRS.

8.7. 为问题 8.3中提出的 PHTRS 系统开发一个类模型。

8.7. Develop a class model for the PHTRS system presented in Problem 8.3.

8.8。在您在问题 8.3中选择的产品或系统上开发一套完整的 CRC 模型索引卡。

8.8. Develop a complete set of CRC model index cards on the product or system you chose as part of Problem 8.3.

8.9。与同事一起审查 CRC 索引卡。审查后添加了多少额外的类、职责和协作者?

8.9. Conduct a review of the CRC index cards with your colleagues. How many additional classes, responsibilities, and collaborators were added as a consequence of the review?

8.10。序列图与状态图有何不同?它们有何相似之处?

8.10. How does a sequence diagram differ from a state diagram? How are they similar?

1本章不再介绍面向流的建模和数据建模。然而,可以在 Web 上找到有关这些旧的需求建模方法的大量信息。如果您有兴趣,请使用搜索短语“结构化分析”。

1 A presentation of flow-oriented modeling and data modeling is no longer included in this chapter. However, copious information about these older requirements modeling methods can be found on the Web. If you have interest, use the search phrase “structured analysis.”

2应该指出的是,随着客户的技术变得越来越成熟,出现了一种趋势,即对如何以及内容进行规范。然而,主要焦点仍应放在什么上。

2 It should be noted that as customers become more technologically sophisticated, there is a trend toward the specification of how as well as what. However, the primary focus should remain on what.

3或者,软件团队可以选择创建原型(第 4 章)以更好地了解系统的需求。

3 Alternatively, the software team may choose to create a prototype (Chapter 4) to better understand requirements for the system.

4 UML 将在本书中用作建模符号。附录 1 为那些可能不熟悉基本 UML 符号的读者提供了一个简短的教程。

4 UML will be used as the modeling notation throughout this book. Appendix 1 provides a brief tutorial for those readers who may be unfamiliar with basic UML notation.

5参与者不是特定的人,而是人(或设备)在特定上下文中扮演的角色。参与者“调用系统提供其中一项服务”[Coc01b]。

5 An actor is not a specific person, but rather a role that a person (or a device) plays within a specific context. An actor “calls on the system to deliver one of its services” [Coc01b].

6用例是用户界面分析建模的一个特别重要的部分。第 12 章详细讨论了接口分析和设计。

6 Use cases are a particularly important part of analysis modeling for user interfaces. Interface analysis and design is discussed in detail in Chapter 12.

7在这种情况下,另一个参与者(系统管理员)必须配置平面图、安装(例如分配设备 ID)所有摄像机并初始化它们,并测试每个摄像机以确保可以通过系统访问它,并且通过平面图。

7 In this case, another actor, the system administrator, would have to configure the floor plan, install (e.g., assign an equipment ID) all cameras and initialize them, and test each camera to be certain that it is accessible via the system and through the floor plan.

8另一个重要的分类,即定义实体、边界和控制器类,在第 10.3 节中讨论。

8 Another important categorization, defining entity, boundary, and controller classes, is discussed in Section 10.3.

9处理叙述在风格上与用例相似,但在目的上有些不同。处理叙述提供了要开发的功能的总体描述。这不是一个从一个演员的角度写的剧本。然而,值得注意的是,语法解析也可以用于作为需求收集(启发)的一部分而开发的每个用例。

9 A processing narrative is similar to the use case in style but somewhat different in purpose. The processing narrative provides an overall description of the function to be developed. It is not a scenario written from one actor’s point of view. It is important to note, however, that a grammatical parse can also be used for every use case developed as part of requirements gathering (elicitation).

10在此示例中,我们假设与SafeHome交互的每个用户(房主)都有一个识别密码,因此是一个合法对象。

10 In this example, we assume that each user (homeowner) that interacts with SafeHome has an identifying password and is therefore a legitimate object.

11如果您不熟悉 UML,附录 1 简要介绍了这一重要的建模符号。

11 If you are unfamiliar with UML, a brief introduction to this important modeling notation is presented in Appendix 1.

第156页

Page 156

章节

chapter

9设计理念

9 Design Concepts

软件设计包含一系列原则、概念和实践,可用于开发高质量的系统或产品。设计原则建立了一种压倒一切的哲学,指导您必须执行的设计工作。在应用设计实践的机制之前必须理解设计概念,设计实践导致创建软件的各种表示形式,作为后续构建活动的指南。

Software design encompasses the set of principles, concepts, and practices that lead to the development of a high-quality system or product. Design principles establish an overriding philosophy that guides the design work you must perform. Design concepts must be understood before the mechanics of design practice are applied, and design practice leads to the creation of various representations of the software that serve as a guide for the construction activity that follows.

第 157 页设计对于成功的软件工程至关重要。一些开发人员倾向于在创建用例后就开始编程,而不考虑实现用例所需的软件组件如何相互关联。通过创建多个软件增量,可以迭代地进行分析、设计和实现。忽视为不断发展的软件产品创建适当的架构所需的设计考虑是一个坏主意。技术债务是软件开发中的一个概念,指的是由于立即选择“快速而肮脏”的解决方案而不是使用需要更多时间的更好方法而导致的返工相关成本。增量构建软件产品时不可避免地会产生技术债务。然而,一个好的开发团队必须通过定期重构(第 9.3.9 节)软件来尝试偿还这种技术债务。就像贷款一样,您可以等到贷款到期并支付大量利息,或者您可以一次偿还少量贷款并支付较少的利息。

Page 157Design is pivotal to successful software engineering. Some developers are tempted to begin programming once the use cases have been created, without regard to how the software components needed to implement the use cases relate to one another. It is possible to do analysis, design, and implementation iteratively by creating several software increments. It is a bad idea to ignore the design considerations needed to create an appropriate architecture for the evolving software product. Technical debt is a concept in software development that refers to costs associated with rework caused by choosing a “quick and dirty” solution right now instead of using a better approach that would take more time. It is impossible to avoid creating technical debt when building a software product incrementally. However, a good development team must try to pay down this technical debt by refactoring (Section 9.3.9) the software on a regular basis. Just like taking out a loan, you can wait until the loan is due and pay a lot of interest or you can pay the loan off a little at a time and pay less interest overall.

在不延迟编码的情况下控制技术债务的一种策略是利用多样化和融合的设计实践。多样化是识别需求模型元素所建议的可能设计替代方案的实践。收敛是评估和拒绝不满足为软件解决方案定义的非功能性需求所施加的约束的设计替代方案的过程。多样化和趋同结合了(1)基于构建类似实体的经验的直觉和判断,(2)指导模型发展方式的一套原则和/或启发法,(3)一套使质量能够进行判断,以及(4)最终形成最终设计表示的迭代过程。一旦以这种方式确定了可行的设计替代方案,开发人员就可以很好地创建不太可能是一次性原型的软件增量。

One strategy to keep technical debt in check without delaying coding is to make use of the design practices of diversification and convergence. Diversification is the practice of identifying possible design alternatives suggested by the elements of the requirements model. Convergence is the process of evaluating and rejecting design alternatives that do not meet the constraints imposed by the nonfunctional requirements defined for the software solution. Diversification and convergence combine (1) intuition and judgment based on experience in building similar entities, (2) a set of principles and/or heuristics that guide the way in which the model evolves, (3) a set of criteria that enables quality to be judged, and (4) a process of iteration that ultimately leads to a final design representation. Once a viable design alternative is identified this way, the developers are in a good position to create a software increment that is not likely to be a throwaway prototype.

随着新方法、更好的分析和更广泛的理解的发展,软件设计不断变化。1即使在今天,大多数软件设计方法仍缺乏通常与更经典的工程设计学科相关的深度、灵活性和定量性质。然而,软件设计的方法确实存在,设计质量的标准是可用的,并且可以应用设计符号。

Software design changes continually as new methods, better analysis, and broader understanding evolve.1 Even today, most software design methodologies lack the depth, flexibility, and quantitative nature that are normally associated with more classical engineering design disciplines. However, methods for software design do exist, criteria for design quality are available, and design notation can be applied.

在本章中,我们探讨适用于所有软件设计的基本概念和原则、设计模型的元素以及模式对设计过程的影响。在第10章第14章中,我们将介绍各种应用于架构、界面和组件级设计以及基于模式、移动和用户体验设计方法的软件设计方法。

In this chapter, we explore the fundamental concepts and principles that are applicable to all software design, the elements of the design model, and the impact of patterns on the design process. In Chapters 10 through 14 we’ll present a variety of software design methods as they are applied to architectural, interface, and component-level design as well as pattern-based, mobile, and user experience design approaches.

9.1 软件工程背景下的设计

9.1 Design Within the Context of Software Engineering

软件设计位于软件工程的技术核心,无论使用何种软件过程模型,软件设计都会被应用。一旦对软件需求进行了分析和建模,软件设计就是建模活动中的最后一个软件工程操作,并为构建(代码生成和测试)奠定了基础。第158页

Software design sits at the technical kernel of software engineering and is applied regardless of the software process model that is used. Beginning once software requirements have been analyzed and modeled, software design is the last software engineering action within the modeling activity and sets the stage for construction (code generation and testing).Page 158

需求模型(第 8 章)的每个元素都提供了创建完整设计规范所需的四个设计模型所需的信息。软件设计过程中的信息流如图9.1所示。需求模型由基于场景、基于类和行为元素体现,为设计任务提供支持。使用后面章节中讨论的设计符号和设计方法,设计产生数据/类设计、体系结构设计、接口设计和组件设计。

Each of the elements of the requirements model (Chapter 8) provide information that is necessary to create the four design models required for a complete specification of design. The flow of information during software design is illustrated in Figure 9.1. The requirements model, manifested by scenario-based, class-based, and behavioral elements, feed the design task. Using design notation and design methods discussed in later chapters, design produces a data/class design, an architectural design, an interface design, and a component design.

9.1 需求模型转化为设计模型

Figure 9.1 Translating the requirements model into the design model

数据/类设计将类模型(第 8 章)转换为设计类实现和实现软件所需的必要数据结构。CRC模型中定义的对象和关系以及类属性和其他表示法描述的详细数据内容为数据设计活动提供了基础。部分类设计可能与软件架构的设计一起发生。当设计每个软件组件时,会发生更详细的类设计。

The data/class design transforms class models (Chapter 8) into design class realizations and the requisite data structures required to implement the software. The objects and relationships defined in the CRC model and the detailed data content depicted by class attributes and other notation provide the basis for the data design activity. Part of class design may occur in conjunction with the design of software architecture. More detailed class design occurs as each software component is designed.

架构设计定义了软件的主要结构元素、架构风格和模式(第 14 章)之间的关系,可用于实现为系统定义的需求,以及影响架构实现方式的约束[沙15]。架构设计表示(基于计算机的系统的框架)源自需求模型。

The architectural design defines the relationship between major structural elements of the software, the architectural style, and patterns (Chapter 14) that can be used to achieve the requirements defined for the system, and the constraints that affect the way in which architecture can be implemented [Sha15]. The architectural design representation—the framework of a computer-based system—is derived from the requirements model.

界面设计描述了软件如何与与其互操作的系统以及使用它的人进行通信。接口意味着信息流(例如,数据和/或控制)和特定类型的行为。因此,使用场景和行为模​​型提供了界面设计所需的大量信息。

The interface design describes how the software communicates with systems that interoperate with it, and with humans who use it. An interface implies a flow of information (e.g., data and/or control) and a specific type of behavior. Therefore, usage scenarios and behavioral models provide much of the information required for interface design.

组件级设计将软件体系结构的结构元素转换为软件组件的过程描述。从基于类的模型和行为模型获得的信息作为组件设计的基础。第 159 页

The component-level design transforms structural elements of the software architecture into a procedural description of software components. Information obtained from the class-based models and behavioral models serve as the basis for component design.Page 159

在设计过程中,您做出的决策将最终影响软件构建的成功,并且同样重要的是,影响软件维护的难易程度。但为什么设计如此重要?

During design you make decisions that will ultimately affect the success of software construction and, just as important, the ease with which software can be maintained. But why is design so important?

软件设计的重要性可以用一个词来形容——质量。设计是软件工程中培养质量的地方。它为您提供可以评估质量的软件表示。设计是将利益相关者的需求准确地转化为最终软件产品或系统的唯一方法。软件设计是后续所有软件工程和软件支持活动的基础。如果没有设计,您将面临构建不稳定系统的风险——如果进行微小的更改,该系统就会失败;可能难以测试的一项;其质量直到软件过程​​后期才能评估。项目后期是指时间紧迫,且许多预算资金已被花费的情况。

The importance of software design can be stated with a single word—quality. Design is the place where quality is fostered in software engineering. It provides you with representations of software that can be assessed for quality. Design is the only way that you can accurately translate stakeholders’ requirements into a finished software product or system. Software design serves as the foundation for all the software engineering and software support activities that follow. Without design, you risk building an unstable system—one that will fail when small changes are made; one that may be difficult to test; one whose quality cannot be assessed until late in the software process. Late in the project is when time is short, and many budgeted dollars have already been spent.

9.2 设计过程

9.2 The Design Process

软件设计是一个迭代过程,通过该过程将需求转化为构建软件的“蓝图”。最初,蓝图描绘了软件的整体视图。也就是说,设计以高抽象级别表示——可以直接追溯到特定系统目标和更详细的数据、功能和行为需求的级别。随着设计迭代的发生,后续的细化会导致抽象级别低得多的设计表示。这些仍然可以追溯到需求,但在这些较低的抽象级别上,联系可能并不明显。第160页

Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software. Initially, the blueprint depicts a holistic view of software. That is, the design is represented at a high level of abstraction—a level that can be directly traced to the specific system objective and more detailed data, functional, and behavioral requirements. As design iterations occur, subsequent refinement leads to design representations at much lower levels of abstraction. These can still be traced to requirements, but the connections may not be obvious at these lower levels of abstraction.Page 160

9.2.1 软件质量指南和属性

9.2.1 Software Quality Guidelines and Attributes

在整个设计过程中,不断发展的设计的质量通过第 16 章中讨论的一系列技术审查进行评估。McGlaughlin [McG91]提出了三个特征作为评估良好设计的指南:

Throughout the design process, the quality of the evolving design is assessed with a series of technical reviews discussed in Chapter 16. McGlaughlin [McG91] suggests three characteristics that serve as a guide for the evaluation of a good design:

  • 设计应该实现需求模型中包含的所有显式需求,并且必须适应利益相关者期望的所有隐式需求。

  • The design should implement all explicit requirements contained in the requirements model, and it must accommodate all the implicit requirements desired by stakeholders.

  • 对于生成代码的人员以及测试和随后支持软件的人员来说,设计应该是可读、易于理解的指南。

  • The design should be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.

  • 设计应该提供软件的完整画面,从实现的角度解决数据、功能和行为领域。

  • The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

这些特征中的每一个都是设计过程的目标。但这些目标是如何实现的呢?

Each of these characteristics is a goal of the design process. But how is each of these goals achieved?

质量指南。为了评估设计表示的质量,您和软件团队的其他成员必须建立良好设计的技术标准。在第 9.3 节中,我们讨论了也可作为软件质量标准的设计概念。暂时请考虑以下准则:

Quality Guidelines. To evaluate the quality of a design representation, you and other members of the software team must establish technical criteria for good design. In Section 9.3, we discuss design concepts that also serve as software quality criteria. For the time being, consider the following guidelines:

  1. 设计应该展示一种架构,该架构(a)是使用可识别的架构风格或模式创建的,(b)由表现出良好设计特征的组件组成(这些将在本章后面讨论),并且(c)可以在一种渐进的方式,2从而促进实施和测试。

  2. A design should exhibit an architecture that (a) has been created using recognizable architectural styles or patterns, (b) is composed of components that exhibit good design characteristics (these are discussed later in this chapter), and (c) can be implemented in an evolutionary fashion,2 thereby facilitating implementation and testing.

  3. 设计应该是模块化的;也就是说,软件应该在逻辑上划分为元素或子系统。

  4. A design should be modular; that is, the software should be logically partitioned into elements or subsystems.

  5. 设计应该包含数据、架构、接口和组件的不同表示。

  6. A design should contain distinct representations of data, architecture, interfaces, and components.

  7. 设计应该产生适合要实现的类的数据结构,并从可识别的数据模式中提取。

  8. A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns.

  9. 设计应该导致组件表现出独立的功能特征。

  10. A design should lead to components that exhibit independent functional characteristics.

  11. 设计应该产生能够降低组件之间以及与外部环境连接的复杂性的接口。

  12. A design should lead to interfaces that reduce the complexity of connections between components and with the external environment.

  13. 应使用可重复的方法来导出设计,该方法由软件需求分析期间获得的信息驱动。

  14. A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

  15. 设计应该使用能够有效传达其含义的符号来表示。

  16. A design should be represented using a notation that effectively communicates its meaning.

第 161 页仅靠机会是无法实现这些设计准则的。它们是通过应用基本设计原则、系统方法和彻底审查来实现的。

Page 161Chance alone will not achieve these design guidelines. They are achieved through the application of fundamental design principles, systematic methodology, and thorough review.

9.2.2 软件设计的演变

9.2.2 The Evolution of Software Design

软件设计的演变是一个持续的过程,目前已经跨越了六十多年。早期的设计工作集中在模块化程序的开发标准[Den73]和以自上而下的“结构化”方式细化软件结构的方法([Wir71]、[Dah72]、[Mil72])。较新的设计方法(例如,[Jac92]、[Gam95])提出了一种面向对象的设计推导方法。最近软件设计的重点是软件架构[Kru06]和可用于实现软件架构和较低级别的设计抽象的设计模式(例如,[Hol06]、[Sha05])。人们越来越重视面向方面的方法(例如,[Cla05]、[Jac04])、模型驱动开发[Sch06]和测试驱动开发[Ast04],这些方法侧重于实现更有效的模块化和架构的技术创建的设计中的结构。

The evolution of software design is a continuing process that has now spanned more than six decades. Early design work concentrated on criteria for the development of modular programs [Den73] and methods for refining software structures in a top-down “structured” manner ([Wir71], [Dah72], [Mil72]). Newer design approaches (e.g., [Jac92], [Gam95]) proposed an object-oriented approach to design derivation. More recent emphasis in software design has been on software architecture [Kru06] and the design patterns that can be used to implement software architectures and lower levels of design abstractions (e.g., [Hol06], [Sha05]). There is a growing emphasis on aspect-oriented methods (e.g., [Cla05], [Jac04]), model-driven development [Sch06], and test-driven development [Ast04], which focus on techniques for achieving more effective modularity and architectural structure in the designs that are created.

在过去的10年里,基于搜索的软件工程(SBSE)技术已经应用于软件工程生命周期的所有阶段,包括设计[Har12]。SBSE 尝试使用自动化搜索技术解决软件工程问题,并辅以运筹学和机器学习算法,为软件开发人员提供设计建议。许多现代软件系统必须适应高度的可变性,无论是部署环境还是​​期望满足的使用场景数量。可变性密集型系统的设计5要求开发人员预测当前设计的产品的未来版本中要修改的功能的未来变化 [Gal16]。对可变性密集型系统设计的详细讨论超出了本书的范围。第162页

In the past 10 years, Search-Based Software Engineering (SBSE) techniques have been applied to all phases of the software engineering life cycle, including design [Har12]. SBSE attempts to solve software engineering problems using automated search techniques augmented by operations research and machine learning algorithms to provide design recommendations to software developers. Many modern software systems must accommodate a high degree of variability, both in their deployment environments and the number of usage scenarios they expected to satisfy. Design of variability-intensive systems5 requires developers to anticipate future changes in the features to be modified in future versions of the product being designed today [Gal16]. A detailed discussion of the design of variability-intensive systems is beyond the scope of this book.Page 162

从刚才提到的工作中发展出来的几种设计方法正在整个行业中得到应用。与第 8 章中介绍的分析方法一样,每种软件设计方法都引入了独特的启发式方法和符号,以及对设计质量特征的某种狭隘观点。然而,这些方法中的每一种都有共同的特征:(1)将需求模型转换为设计表示的机制,(2)用于表示功能组件及其接口的符号,(3)用于细化和划分的启发式方法,以及(4)质量评估指南。

Several design methods, growing out of the work just noted, are being applied throughout the industry. Like the analysis methods presented in Chapter 8, each software design method introduces unique heuristics and notation, as well as a somewhat parochial view of what characterizes design quality. Yet, each of these methods has common characteristics: (1) a mechanism for the translation of the requirements model into a design representation, (2) a notation for representing functional components and their interfaces, (3) heuristics for refinement and partitioning, and (4) guidelines for quality assessment.

无论使用哪种设计方法,您都应该将一组基本概念应用于数据、体系结构、接口和组件级设计。这些概念将在接下来的部分中讨论。

Regardless of the design method that is used, you should apply a set of basic concepts to data, architectural, interface, and component-level design. These concepts are considered in the sections that follow.

第163页

Page 163

9.3 设计理念

9.3 Design Concepts

几个基本的软件设计概念在软件工程的历史中不断发展。尽管多年来人们对这些概念的兴趣程度有所不同,但每个概念都经受住了时间的考验。每一个都为软件设计者提供了应用更复杂的设计方法的基础。每个都可以帮助您定义可用于将软件划分为各个组件的标准,从软件的概念表示中分离出数据结构细节,并建立定义软件设计的技术质量的统一标准。这些概念帮助开发人员设计实际需要的软件,而不是简单地专注于创建任何旧的工作程序。

Several fundamental software design concepts have evolved over the history of software engineering. Although the degree of interest in these concepts has varied over the years, each has stood the test of time. Each provides the software designer with a foundation from which more sophisticated design methods can be applied. Each helps you define criteria that can be used to partition software into individual components, separate out data structure detail from a conceptual representation of the software, and establish uniform criteria that define the technical quality of a software design. These concepts help developers design the software actually needed, rather than simply focusing on creating any old working program.

9.3.1 抽象

9.3.1 Abstraction

当您考虑任何问题的模块化解决方案时,可以提出许多抽象级别。在最高的抽象层次上,解决方案是使用问题环境的语言(例如,用户故事)从广义上表述的。在较低的抽象级别,提供了解决方案的更详细的描述。面向问题的术语与面向实现的术语相结合来陈述解决方案(例如,用例)。最后,在最低抽象级别,解决方案以可以直接实现的方式(例如伪代码)来表述。

When you consider a modular solution to any problem, many levels of abstraction can be posed. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment (e.g., a user story). At lower levels of abstraction, a more detailed description of the solution is provided. Problem-oriented terminology is coupled with implementation-oriented terminology to state a solution (e.g., use case). Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented (e.g., pseudocode).

随着不同抽象级别的开发,您将努力创建过程抽象和数据抽象。过程抽象是指具有特定且有限功能的指令序列。过程抽象的名称暗示了这些功能,但具体细节被隐藏。程序抽象的一个例子是SafeHome系统中相机的使用一词。使用意味着一长串的程序步骤(例如,在移动设备上激活SafeHome系统、登录SafeHome系统、选择要预览的摄像头、在移动应用程序用户界面上找到摄像头控件等)。6

As different levels of abstraction are developed, you work to create both procedural and data abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed. An example of a procedural abstraction would be the word use for a camera in the SafeHome system. Use implies a long sequence of procedural steps (e.g., activate the SafeHome system on a mobile device, log on to the SafeHome system, select a camera to preview, locate the camera controls on mobile app user interface, etc.).6

数据抽象是描述数据对象的命名数据集合。在开放的过程抽象的背景下我们可以定义一个称为相机的数据抽象与任何数据对象一样,相机的数据抽象将包含一组描述相机的属性(例如,相机ID、位置、视野、摇摄角度、变焦)。由此可见,程序抽象使用将利用数据抽象相机的属性中包含的信息。

A data abstraction is a named collection of data that describes a data object. In the context of the procedural abstraction open, we can define a data abstraction called camera. Like any data object, the data abstraction for camera would encompass a set of attributes that describe the camera (e.g., camera ID, location, field view, pan angle, zoom). It follows that the procedural abstraction use would make use of information contained in the attributes of the data abstraction camera.

9.3.2 架构

9.3.2 Architecture

软件架构指的是“软件的整体结构以及该结构为系统提供概念完整性的方式”[Sha15]。最简单的形式是,架构是程序组件(模块)的结构或组织、这些组件交互的方式以及组件使用的数据的结构。然而,从更广泛的意义上讲,组件可以概括为表示主要系统元素及其交互。第164页

Software architecture alludes to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system” [Sha15]. In its simplest form, architecture is the structure or organization of program components (modules), the ways in which these components interact, and the structure of data that are used by the components. In a broader sense, however, components can be generalized to represent major system elements and their interactions.Page 164

软件设计的目标之一是获得系统的架构渲染。该渲染图作为一个框架,在此基础上进行更详细的设计活动。一组架构模式使软件工程师能够重用设计级概念。

One goal of software design is to derive an architectural rendering of a system. This rendering serves as a framework from which more detailed design activities are conducted. A set of architectural patterns enables a software engineer to reuse design-level concepts.

Shaw 和 Garlan [Sha15] 描述了一组应指定为架构设计一部分的属性。结构属性定义了“系统的组件(例如,模块、对象、过滤器)以及这些组件打包和交互的方式”。额外功能属性解决“设计架构如何实现性能、容量、可靠性、安全性、适应性和其他系统特性(例如非功能系统要求)的要求”。相关系统系列“借鉴了类似系统系列设计中常见的可重复模式。” 7

Shaw and Garlan [Sha15] describe a set of properties that should be specified as part of an architectural design. Structural properties define “the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another.” Extra-functional properties address “how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics (e.g., nonfunctional system requirements).” Families of related systems “draw upon repeatable patterns that are commonly encountered in the design of families of similar systems.”7

给定这些属性的规范,可以使用几种不同模型中的一个或多个来表示架构设计[Gar95]。结构模型将体系结构表示为程序组件的有组织的集合。框架模型通过尝试识别在类似类型的应用程序中遇到的可重复的体系结构设计框架(模式)来提高设计抽象级别。动态模型解决程序架构的行为方面,指示结构或系统配置如何根据外部事件而变化。流程模型侧重于系统必须适应的业务或技术流程的设计。最后,功能模型可用于表示系统的功能层次结构。

Given the specification of these properties, the architectural design can be represented using one or more of several different models [Gar95]. Structural models represent architecture as an organized collection of program components. Framework models increase the level of design abstraction by attempting to identify repeatable architectural design frameworks (patterns) that are encountered in similar types of applications. Dynamic models address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of external events. Process models focus on the design of the business or technical process that the system must accommodate. Finally, functional models can be used to represent the functional hierarchy of a system.

已经开发了几种不同的架构描述语言(ADL)来表示这些模型[Sha15]。尽管已经提出了许多不同的 ADL,但大多数都提供了描述系统组件的机制以及它们相互连接的方式。

Several different architectural description languages (ADLs) have been developed to represent these models [Sha15]. Although many different ADLs have been proposed, the majority provide mechanisms for describing system components and the ways in which they are connected to one another.

您应该注意到,关于架构在设计中的作用存在一些争论。一些研究人员认为,软件架构的推导应该与设计分离,并发生在需求工程操作和更传统的设计操作之间。其他人则认为架构的推导是设计过程中不可或缺的一部分。第 10 章讨论了软件架构的表征方式及其在设计中的作用。

You should note that there is some debate about the role of architecture in design. Some researchers argue that the derivation of software architecture should be separated from design and occurs between requirements engineering actions and more conventional design actions. Others believe that the derivation of architecture is an integral part of the design process. The ways in which software architecture is characterized and its role in design are discussed in Chapter 10.

9.3.3 模式

9.3.3 Patterns

Brad Appleton按以下方式定义了设计模式:“模式是一种命名的洞察力,它传达了在竞争关注点中的特定上下文中针对重复出现的问题的经过验证的解决方案的本质”[App00] 换句话说,设计模式描述了一种设计结构,该结构在特定上下文中以及可能对模式应用和使用方式产生影响的“力量”中解决了明确定义的设计问题。第165页

Brad Appleton defines a design pattern in the following manner: “A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns” [App00]. Stated in another way, a design pattern describes a design structure that solves a well-defined design problem within a specific context and amid “forces” that may have an impact on the manner in which the pattern is applied and used.Page 165

每个设计模式的目的是提供一个描述,使设计人员能够确定(1)该模式是否适用于当前工作,(2)该模式是否可以重用(因此,节省设计时间),以及(3) )该模式是否可以作为开发类似但功能或结构不同的模式的指南。设计模式将在第 14 章中详细讨论。

The intent of each design pattern is to provide a description that enables a designer to determine (1) whether the pattern is applicable to the current work, (2) whether the pattern can be reused (hence, saving design time), and (3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally different, pattern. Design patterns are discussed in detail in Chapter 14.

9.3.4 关注点分离

9.3.4 Separation of Concerns

关注点分离是一种设计概念 [Dij82],它表明,如果将任何复杂问题细分为可以独立解决和/或优化的小块,则可以更轻松地处理任何复杂问题。关注点是指定为软件需求模型一部分的功能或行为。通过将关注点分解为更小、更易于管理的部分,解决问题所需的精力和时间会更少。

Separation of concerns is a design concept [Dij82] that suggests that any complex problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently. A concern is a feature or behavior that is specified as part of the requirements model for the software. By separating concerns into smaller and therefore more manageable pieces, a problem takes less effort and time to solve.

由此可见,两个问题组合时的感知复杂性通常大于单独解决每个问题时的感知复杂性之和。这导致了分而治之的策略——当你把一个复杂的问题分解成可管理的部分时,解决它会更容易。这对于软件模块化具有重要意义。

It follows that the perceived complexity of two problems when they are combined is often greater than the sum of the perceived complexity when each is taken separately. This leads to a divide-and-conquer strategy—it’s easier to solve a complex problem when you break it into manageable pieces. This has important implications for software modularity.

关注点分离还体现在其他相关的设计概念中:模块化、功能独立性和精细化。每一个都将在接下来的小节中讨论。

Separation of concerns is manifested in other related design concepts: modularity, functional independence, and refinement. Each will be discussed in the subsections that follow.

9.3.5 模块化

9.3.5 Modularity

模块化是关注点分离的最常见表现。软件分为单独命名和可寻址的组件,有时称为模块,将它们集成起来以满足问题需求。

Modularity is the most common manifestation of separation of concerns. Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements.

有人指出,“模块化是软件的单一属性,它允许程序被智能地管理”[Mye78]。软件工程师无法轻易掌握单体软件(即由单个模块组成的大型程序)。控制路径的数量、参考范围、变量数量和总体复杂性将使理解几乎不可能。在几乎所有情况下,您都应该将设计分解为许多模块,希望使理解更容易并降低构建软件所需的成本。

It has been stated that “modularity is the single attribute of software that allows a program to be intellectually manageable” [Mye78]. Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer. The number of control paths, span of reference, number of variables, and overall complexity would make understanding close to impossible. In almost all instances, you should break the design into many modules, hoping to make understanding easier and reduce the cost required to build the software.

回想一下我们对关注点分离的讨论,可以得出这样的结论:如果无限地细分软件,开发它所需的工作量将变得可以忽略不计!不幸的是,其他力量的作用,导致这个结论(遗憾的是)无效。参考图 9.2,随着模块总数的增加,开发单个软件模块的工作量(成本)趋于减少。

Recalling our discussion of separation of concerns, it is possible to conclude that if you subdivide software indefinitely the effort required to develop it will become negligibly small! Unfortunately, other forces come into play, causing this conclusion to be (sadly) invalid. Referring to Figure 9.2, the effort (cost) to develop an individual software module tends to decrease as the total number of modules increases.

图9.2模块化 和软件成本

Figure 9.2 Modularity and software cost

给定相同的要求,程序中使用的模块越多意味着单个尺寸越小。然而,随着模块数量的增加,与模块相互集成相关的工作量(成本)也随之增加。这些特征导致总成本或工作量曲线,如图9.2所示。有M个模块可以将开发成本降至最低,但我们没有必要的复杂性来有把握地预测M。

Given the same set of requirements, the more modules used in your program means smaller individual sizes. However, as the number of modules grows, the effort (cost) associated with integrating modules with each other grows. These characteristics lead to a total cost or effort curve, shown in Figure 9.2. There is a number, M, of modules that would result in minimum development cost, but we do not have the necessary sophistication to predict M with assurance.

当考虑模块化时,图 9.2中所示的曲线确实提供了有用的定性指导。你应该模块化,但要注意保持在M附近。应避免使用太少的模块或太多的模块。但你怎么知道M的附近呢?您应该如何模块化地开发软件?要回答这些问题,需要了解第 9.3.6 节第 9.3.9节中考虑的其他设计概念。第166页

The curves shown in Figure 9.2 do provide useful qualitative guidance when modularity is considered. You should modularize, but care should be taken to stay in the vicinity of M. Using too few modules or too many modules should be avoided. But how do you know the vicinity of M? How modular should you make software? The answers to these questions require an understanding of other design concepts considered in Sections 9.3.6 through 9.3.9.Page 166

您可以对设计(以及生成的程序)进行模块化,以便更轻松地规划开发、定义和交付软件增量、更轻松地适应变更、更有效地进行测试和调试以及可以更有效地进行长期维护。进行时没有严重的副作用。

You modularize a design (and the resulting program) so that development can be more easily planned, software increments can be defined and delivered, changes can be more easily accommodated, testing and debugging can be conducted more efficiently, and long-term maintenance can be conducted without serious side effects.

9.3.6 信息隐藏

9.3.6 Information Hiding

模块化的概念引出了一个基本问题:“如何分解软件解决方案以获得最佳的模块集?” 信息隐藏原则[Par72] 表明模块应该“以(每个)对所有其他模块隐藏的设计决策为特征”。换句话说,应该指定和设计模块,以便模块中包含的信息(算法和数据)不能被不需要此类信息的其他模块访问。

The concept of modularity leads you to a fundamental question: “How do I decompose a software solution to obtain the best set of modules?” The principle of information hiding [Par72] suggests that modules should be “characterized by design decisions that (each) hides from all others.” In other words, modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information.

隐藏意味着可以通过定义一组独立的模块来实现有效的模块化,这些模块仅相互通信实现软件功能所需的信息。抽象有助于定义构成软件的程序(或信息)实体。隐藏定义并强制执行对模块内的过程细节和模块使用的任何本地数据结构的访问约束[Ros75]。

Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function. Abstraction helps to define the procedural (or informational) entities that make up the software. Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module [Ros75].

当测试期间和随后的软件维护期间需要修改时,使用信息隐藏作为模块化系统的设计标准可以提供最大的好处。由于大多数数据和程序细节对软件的其他部分是隐藏的,因此修改期间引入的无意错误不太可能传播到软件内的其他位置。第 167 页

The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later during software maintenance. Because most data and procedural detail are hidden from other parts of the software, inadvertent errors introduced during modification are less likely to propagate to other locations within the software.Page 167

9.3.7 功能独立性

9.3.7 Functional Independence

功能独立的概念是关注点分离、模块化以及抽象和信息隐藏概念的直接产物。在关于软件设计的里程碑式论文中,Wirth [Wir71] 和 Parnas [Par72] 都提到了增强模块独立性的细化技术。Stevens、Myers 和 Constantine [Ste74] 后来的工作巩固了这个概念。

The concept of functional independence is a direct outgrowth of separation of concerns, modularity, and the concepts of abstraction and information hiding. In landmark papers on software design, Wirth [Wir71] and Parnas [Par72] each allude to refinement techniques that enhance module independence. Later work by Stevens, Myers, and Constantine [Ste74] solidified the concept.

功能独立性是通过开发具有“专一”功能和“厌恶”与其他模块过度交互的模块来实现的。换句话说,您应该设计软件,以便每个模块都能满足特定的需求子集,并且从程序结构的其他部分查看时具有简单的界面。

Functional independence is achieved by developing modules with “single-minded” function and an “aversion” to excessive interaction with other modules. Stated another way, you should design software so that each module addresses a specific subset of requirements and has a simple interface when viewed from other parts of the program structure.

公平地说,为什么独立很重要。具有有效模块化(即独立模块)的软件更容易开发,因为可以划分功能,简化接口(考虑团队开发时的后果)。独立的模块更容易维护(和测试),因为设计或代码修改引起的二次影响是有限的,错误传播减少了,并且可以重用模块。总而言之,功能独立性是良好设计的关键,而设计是软件质量的关键。评估 CRC 卡模型(第 8 章)可以帮助您发现功能独立性问题。包含许多诸如andexcept之类的单词实例的用户故事不太可能鼓励您设计“一心一意”的系统功能模块。

It is fair to ask why independence is important. Software with effective modularity, that is, independent modules, is easier to develop because function can be compartmentalized and interfaces are simplified (consider the ramifications when development is conducted by a team). Independent modules are easier to maintain (and test) because secondary effects caused by design or code modification are limited, error propagation is reduced, and reusable modules are possible. To summarize, functional independence is a key to good design, and design is the key to software quality. Evaluation of your CRC card model (Chapter 8) can help you spot problems with functional independence. User stories that contain many instances of words such as and or except are not likely to encourage you to design modules that are “single-minded” system functions.

使用两个定性标准评估独立性:内聚性和耦合性。内聚力指示模块的相对功能强度。耦合是模块之间相对相互依赖关系的指示。

Independence is assessed using two qualitative criteria: cohesion and coupling. Cohesion is an indication of the relative functional strength of a module. Coupling is an indication of the relative interdependence among modules.

内聚是第 9.3.6 节中描述的信息隐藏概念的自然延伸。内聚模块执行单个任务,几乎不需要与程序其他部分中的其他组件进行交互。简单地说,一个内聚模块应该(理想地)只做一件事。尽管您应该始终努力实现高内聚性(即一心一意),但让一个软件组件执行多种功能通常是必要且可取的。然而,如果要实现良好的设计,就应该避免“精神分裂”的组件(执行许多不相关功能的模块)。

Cohesion is a natural extension of the information-hiding concept described in Section 9.3.6. A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. Although you should always strive for high cohesion (i.e., single-mindedness), it is often necessary and advisable to have a software component perform multiple functions. However, “schizophrenic” components (modules that perform many unrelated functions) are to be avoided if a good design is to be achieved.

耦合是软件结构中模块之间互连的指示。耦合取决于模块之间的接口复杂性、对模块进行输入或引用的点以及通过接口传递的数据。在软件设计中,应该力求尽可能低的耦合。模块之间的简单连接使软件更易于理解,并且不太可能将一个模块中发现的错误传播到其他系统模块。

Coupling is an indication of interconnections among modules in a software structure. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface. In software design, you should strive for the lowest possible coupling. Simple connectivity among modules results in software that is easier to understand and less likely to propagate errors found in one module to other system modules.

9.3.8 逐步细化

9.3.8 Stepwise Refinement

逐步细化是一种自上而下的设计策略,最初由 Niklaus Wirth [Wir71] 提出。不断细化程序细节级别是开发应用程序的好方法。层次结构是通过逐步分解宏观的函数语句(过程抽象)直到达到编程语言语句来开发的。

Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth [Wir71]. Successively refining levels of procedural detail is a good way to develop an application. A hierarchy is developed by decomposing a macroscopic statement of function (a procedural abstraction) in a stepwise fashion until programming language statements are reached.

细化是一个细化的过程您从在高抽象级别定义的功能声明(或信息描述)开始。也就是说,该声明概念性地描述了功能或信息,但没有提供功能的内部运作或信息的内部结构的指示。然后,您详细阐述原始陈述,并在每次后续细化(阐述)发生时提供更多细节。第168页

Refinement is a process of elaboration. You begin with a statement of function (or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information conceptually but provides no indication of the internal workings of the function or the internal structure of the information. You then elaborate on the original statement, providing more detail as each successive refinement (elaboration) occurs.Page 168

抽象和细化是互补的概念。抽象使您能够在内部指定过程和数据,但抑制“外部人员”了解低级细节的需要。随着设计的进展,细化可以帮助您揭示低级细节。这两个概念都允许您随着设计的发展创建完整的设计模型。

Abstraction and refinement are complementary concepts. Abstraction enables you to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details. Refinement helps you to reveal low-level details as design progresses. Both concepts allow you to create a complete design model as the design evolves.

9.3.9 重构

9.3.9 Refactoring

对于许多敏捷方法(第 3 章)来说,重构是一项重要的设计活动,它是一种重组技术,可以简化组件的设计(或代码)而不改变其功能或行为。Fowler [Fow00] 按以下方式定义重构:“重构是改变软件系统的过程,其方式不会改变代码[设计]的外部行为,但会改进其内部结构。”

An important design activity suggested for many agile methods (Chapter 3), refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior. Fowler [Fow00] defines refactoring in the following manner: “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.”

当重构软件时,会检查现有设计是否存在冗余、未使用的设计元素、低效或不必要的算法、构造不良或不适当的数据结构,或任何其他可以纠正以产生更好的设计的设计故障。例如,第一次设计迭代可能会产生一个表现出低内聚性的大型组件(即,它执行三个彼此之间只有有限关系的功能)。经过仔细考虑,您可能决定将该组件重构为三个独立的组件,每个组件都表现出高内聚性。结果将是更容易集成、更容易测试和更容易维护的软件。

When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failure that can be corrected to yield a better design. For example, a first design iteration might yield a large component that exhibits low cohesion (i.e., it performs three functions that have only a limited relationship to one another). After careful consideration, you may decide that the component should be refactored into three separate components, each of which exhibits high cohesion. The result will be software that is easier to integrate, easier to test, and easier to maintain.

尽管重构的目的是以不改变其外部行为的方式修改代码,但无意的副作用可能而且确实会发生。重构工具 [Soa10] 有时用于自动分析代码更改并“生成适合检测行为更改的测试套件”。

Although the intent of refactoring is to modify the code in a manner that does not alter its external behavior, inadvertent side effects can and do occur. Refactoring tools [Soa10] are sometimes used to analyze code changes automatically and to “generate a test suite suitable for detecting behavioral changes.”

9.3.10 设计类

9.3.10 Design Classes

分析模型定义了一组分析类(第8章)。每个类都描述了问题域的一些元素,重点关注用户可见的问题的各个方面。分析类的抽象程度比较高。

The analysis model defines a set of analysis classes (Chapter 8). Each of these classes describes some element of the problem domain, focusing on aspects of the problem that are user visible. The level of abstraction of an analysis class is relatively high.

随着设计模型的发展,您将定义一组设计类,通过提供设计细节来细化分析类,这些设计细节将使这些类得以实现并创建支持业务解决方案的软件基础结构。

As the design model evolves, you will define a set of design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented and to create a software infrastructure that supports the business solution.

随着软件架构的形成,抽象层次会随着每个分析类(第 8 章)转换为设计表示而降低。也就是说,分析类表示数据对象和应用于它们的关联服务。设计课程提供了更多的技术细节作为实施指南。

As the software architecture forms, the level of abstraction is reduced as each analysis class (Chapter 8) is transformed into a design representation. That is, analysis classes represent data objects and associated services that are applied to them. Design classes present significantly more technical detail as a guide for implementation.

Arlow 和 Neustadt [Arl02] 建议审查每个设计类以确保其“格式良好”。他们定义了格式良好的设计类的四个特征:

Arlow and Neustadt [Arl02] suggest that each design class be reviewed to ensure that it is “well-formed.” They define four characteristics of a well-formed design class:

完整且充分。设计类应该是该类存在的所有属性和方法的完整封装(基于对类名的专业解释)。例如,为SafeHome房间布局软件定义的FloorPlan类(图 9.3)只有包含可以与平面图创建合理关联的所有属性和方法时才是完整的。充分性确保设计类仅包含那些足以实现类意图的方法,不多也不少。

Complete and sufficient. A design class should be the complete encapsulation of all attributes and methods that can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class. For example, the class FloorPlan (Figure 9.3) defined for the SafeHome room layout software is complete only if it contains all attributes and methods that can reasonably be associated with the creation of a floor plan. Sufficiency ensures that the design class contains only those methods that are sufficient to achieve the intent of the class, no more and no less.

图9.3 FloorPlan 的设计类和该类的复合聚合(参见边栏讨论

Figure 9.3 Design class for FloorPlan and composite aggregation for the class (see sidebar discussion)

原始性。与设计类相关的方法应该集中于为该类完成一项服务。一旦使用方法实现了服务,类就不应该提供另一种方法来完成同样的事情。例如,房间布局软件使用的Segment类(图 9.3startCoordinate )可能具有属性和endCoordinate来指示要绘制的线段的起点和终点。setCoordinates()方法提供了建立线段起点和终点的唯一方法。第 170 页

Primitiveness. Methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, the class should not provide another way to accomplish the same thing. For example, the class Segment (Figure 9.3) for use by the room layout software might have attributes startCoordinate and endCoordinate to indicate the start and end points of the segment to be drawn. The method setCoordinates() provides the only means for establishing start and end points for the segment.Page 170

高凝聚力。一个内聚的设计类有一个小的、集中的职责集,并且一心一意地应用属性和方法来实现这些职责。例如,FloorPlan类(图 9.3)可能包含一组用于编辑房屋平面图的方法。只要每种方法只关注与平面图相关的属性,就可以保持凝聚力。

High cohesion. A cohesive design class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities. For example, the class FloorPlan (Figure 9.3) might contain a set of methods for editing the house floor plan. As long as each method focuses solely on attributes associated with the floor plan, cohesion is maintained.

低耦合。在设计模型中,设计类之间有必要相互协作。然而,合作应保持在可接受的最低限度。如果设计模型是高度耦合的(所有设计类与所有其他设计类协作),那么随着时间的推移,系统将很难实现、测试和维护。一般来说,子系统中的设计类应该只了解其他类的有限知识。这个限制被称为Demeter 定律[Lie03] 它表明一个方法应该只向相邻类中的方法发送消息。8第 171 页

Low coupling. Within the design model, it is necessary for design classes to collaborate with one another. However, collaboration should be kept to an acceptable minimum. If a design model is highly coupled (all design classes collaborate with all other design classes), the system is difficult to implement, to test, and to maintain over time. In general, design classes within a subsystem should have only limited knowledge of other classes. This restriction, called the Law of Demeter [Lie03], suggests that a method should only send messages to methods in neighboring classes.8Page 171

9.4 设计模型

9.4 The Design Model

软件设计模型相当于建筑师的房屋平面图。它首先表示要建造的事物的整体(例如,房屋的三维渲染),然后慢慢地细化该事物,为构建每个细节(例如,管道布局)提供指导。同样,为软件创建的设计模型提供了系统的各种不同视图。

The software design model is the equivalent of an architect’s plans for a house. It begins by representing the totality of the thing to be built (e.g., a three-dimensional rendering of the house) and slowly refines the thing to provide guidance for constructing each detail (e.g., the plumbing layout). Similarly, the design model that is created for software provides a variety of different views of the system.

设计模型可以从两个不同的维度来查看,如图 9.4 所示过程维度表明设计模型的演变,因为设计任务作为软件过程的一部分执行。抽象维度表示分析模型的每个元素转换为等效设计然后迭代细化时的详细程度。参见该图,虚线表示分析模型和设计模型之间的边界。在某些情况下,分析模型和设计模型之间的明显区别是可能的。在其他情况下,分析模型会慢慢融入设计中,并且明显的区别不太明显。

The design model can be viewed in two different dimensions, as illustrated in Figure 9.4. The process dimension indicates the evolution of the design model as design tasks are executed as part of the software process. The abstraction dimension represents the level of detail as each element of the analysis model is transformed into a design equivalent and then refined iteratively. Referring to the figure, the dashed line indicates the boundary between the analysis and design models. In some cases, a clear distinction between the analysis and design models is possible. In other cases, the analysis model slowly blends into the design and a clear distinction is less obvious.

9.4 设计模型尺寸

Figure 9.4 Dimensions of the design model

第 172 页设计模型的元素使用许多与分析模型中使用的相同的 UML 图9 。不同之处在于,这些图表是作为设计的一部分进行细化和阐述的;提供了更多特定于实现的细节,并且强调了架构结构和风格、驻留在架构内的组件以及组件之间以及与外部世界的接口。

Page 172The elements of the design model use many of the same UML diagrams9 that were used in the analysis model. The difference is that these diagrams are refined and elaborated as part of design; more implementation-specific detail is provided, and architectural structure and style, components that reside within the architecture, and interfaces between the components and with the outside world are all emphasized.

但是,您应该注意,沿水平轴指示的模型元素并不总是以顺序方式开发。在大多数情况下,初步的架构设计奠定了基础,然后是接口设计和组件级设计,这通常是并行发生的。部署模型通常会延迟到设计完全开发出来为止。

You should note, however, that model elements indicated along the horizontal axis are not always developed in a sequential fashion. In most cases, preliminary architectural design sets the stage and is followed by interface design and component-level design, which often occur in parallel. The deployment model is usually delayed until the design has been fully developed.

您可以在设计过程中的任何时候应用设计模式(第 14 章)。这些模式使您能够将设计知识应用于其他人遇到和解决的特定领域问题。第 173 页

You can apply design patterns (Chapter 14) at any point during design. These patterns enable you to apply design knowledge to domain-specific problems that have been encountered and solved by others.Page 173

9.4.1 设计建模原则

9.4.1 Design Modeling Principles

不乏导出软件设计模型的各种元素的方法。有些方法是数据驱动的,允许数据结构决定程序架构和最终的处理组件。其他的是模式驱动的,使用有关问题域(需求模型)的信息来开发架构风格和处理模式。还有一些是面向对象的,使用问题域对象作为创建数据结构和操作它们的方法的驱动程序。然而,无论使用哪种方法,所有这些都包含一组可以应用的设计原则:

There is no shortage of methods for deriving the various elements of a software design model. Some methods are data driven, allowing the data structure to dictate the program architecture and the resultant processing components. Others are pattern driven, using information about the problem domain (the requirements model) to develop architectural styles and processing patterns. Still others are object oriented, using problem domain objects as the driver for the creation of data structures and the methods that manipulate them. Yet all embrace a set of design principles that can be applied, regardless of the method that is used:

原则 1.设计应该可追溯到需求模型。需求模型描述了问题的信息域、用户可见的功能、系统行为以及一组需求类,这些类将业务对象与服务它们的方法打包在一起。设计模型将这些信息转化为体系结构、一组实现主要功能的子系统以及一组实现需求类的组件。设计模型的元素应该可追溯到需求模型。

Principle 1. Design should be traceable to the requirements model. The requirements model describes the information domain of the problem, user-visible functions, system behavior, and a set of requirements classes that package business objects with the methods that service them. The design model translates this information into an architecture, a set of subsystems that implement major functions, and a set of components that are the realization of requirements classes. The elements of the design model should be traceable to the requirements model.

原则 2.始终考虑要构建的系统的架构。软件架构(第10章)是要构建的系统的骨架。它影响接口、数据结构、程序控制流和行为、进行测试的方式、最终系统的可维护性等等。出于所有这些原因,设计应该从架构考虑开始。只有在架构建立之后才应该考虑组件级问题。

Principle 2. Always consider the architecture of the system to be built. Software architecture (Chapter 10) is the skeleton of the system to be built. It affects interfaces, data structures, program control flow and behavior, the manner in which testing can be conducted, the maintainability of the resultant system, and much more. For all these reasons, design should start with architectural considerations. Only after the architecture has been established should component-level issues be considered.

原则3.数据的设计与处理功能的设计同样重要。数据设计是架构设计的重要组成部分。在设计中实现数据对象的方式不能靠运气。结构良好的数据设计有助于简化程序流程,使软件组件的设计和实现更加容易,并使整体处理更加高效。

Principle 3. Design of data is as important as design of processing functions. Data design is an essential element of architectural design. The ways in which data objects are realized within the design cannot be left to chance. A well-structured data design helps to simplify program flow, makes the design and implementation of software components easier, and makes overall processing more efficient.

原则 4.接口(内部和外部)必须谨慎设计。数据在系统组件之间流动的方式与处理效率、错误传播和设计简单性有很大关系。精心设计的界面使集成变得更加容易,并帮助测试人员验证组件功能。

Principle 4. Interfaces (both internal and external) must be designed with care. The ways in which data flows between the components of a system has much to do with processing efficiency, error propagation, and design simplicity. A well-designed interface makes integration easier and assists the tester in validating component functions.

原则 5.用户界面设计应适应最终用户的需求。然而,在任何情况下,都应该强调易用性。用户界面是软件的可视化表现。无论其内部功能多么复杂,无论其数据结构多么全面,无论其架构设计得多么出色,糟糕的界面设计往往会导致人们认为该软件“很糟糕”。

Principle 5. User interface design should be tuned to the needs of the end user. However, in every case, it should stress ease of use. The user interface is the visible manifestation of the software. No matter how sophisticated its internal functions, no matter how comprehensive its data structures, no matter how well designed its architecture, a poor interface design often leads to the perception that the software is “bad.”

原则 6.组件级设计应该在功能上独立。功能独立性是衡量软件组件“单一性”的标准。组件提供的功能应该是内聚的,也就是说,它应该只关注一个功能。

Principle 6. Component-level design should be functionally independent. Functional independence is a measure of the “single-mindedness” of a software component. The functionality that is delivered by a component should be cohesive—that is, it should focus on one and only one function.

第 174 页原则 7.组件之间以及组件与外部环境之间应该是松散耦合的。耦合可以通过多种方式实现——通过组件接口、消息传递和全局数据。随着耦合程度的增加,错误传播的可能性也会增加,软件的整体可维护性也会降低。因此,组件耦合应保持在合理的最低水平。

Page 174Principle 7. Components should be loosely coupled to one another and to the external environment. Coupling is achieved in many ways—via a component interface, by messaging, and through global data. As the level of coupling increases, the likelihood of error propagation also increases and the overall maintainability of the software decreases. Therefore, component coupling should be kept as low as is reasonable.

原则 8.设计表示(模型)应该易于理解。设计的目的是向将生成代码的从业者、将测试软件的人员以及将来可能维护该软件的其他人传达信息。如果设计难以理解,它就不能作为有效的沟通媒介。

Principle 8. Design representations (models) should be easily understandable. The purpose of design is to communicate information to practitioners who will generate code, to those who will test the software, and to others who may maintain the software in the future. If the design is difficult to understand, it will not serve as an effective communication medium.

原则 9.设计应该迭代开发。在每次迭代中,设计师都应该力求更加简单。与几乎所有创意活动一样,设计是迭代进行的。第一次迭代致力于完善设计并纠正错误,但后续迭代应努力使设计尽可能简单。

Principle 9. The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity. Like almost all creative activities, design occurs iteratively. The first iterations work to refine the design and correct errors, but later iterations should strive to make the design as simple as is possible.

原则 10:设计模型的创建并不排除敏捷方法。敏捷软件开发的一些支持者(第 3 章)坚持认为代码是唯一需要的设计文档。然而,设计模型的目的是帮助其他必须维护和发展系统的人。在现代多线程运行时环境中,理解代码片段的高级用途或其与其他模块的交互是极其困难的。

Principle 10. Creation of a design model does not preclude an agile approach. Some proponents of agile software development (Chapter 3) insist that the code is the only design documentation that is needed. Yet the purpose of a design model is to help others who must maintain and evolve the system. It is extremely difficult to understand either the higher-level purpose of a code fragment or its interactions with other modules in a modern multithreaded run-time environment.

敏捷设计文档应与设计和开发保持同步,以便在项目结束时以允许理解和维护代码的级别记录设计。设计模型提供了好处,因为它是在抽象级别上创建的,去除了不必要的技术细节,并且与应用程序概念和需求紧密耦合。补充设计信息可以包含设计原理,包括被拒绝的建筑设计替代方案的描述。

Agile design documentation should be kept in sync with the design and development, so that at the end of the project the design is documented at a level that allows the code to be understood and maintained. The design model provides benefit because it is created at a level of abstraction that is stripped of unnecessary technical detail and is closely coupled to the application concepts and requirements. Complementary design information can incorporate a design rationale, including the descriptions of rejected architectural design alternatives.

9.4.2 数据设计元素

9.4.2 Data Design Elements

与其他软件工程活动一样,数据设计(有时称为数据架构)创建以高抽象级别(客户或用户的数据视图)表示的数据和/或信息模型。然后,该数据模型被细化为逐渐更加特定于实现的表示形式,可以由基于计算机的系统进行处理。在许多软件应用程序中,数据的架构将对必须处理数据的软件的架构产生深远的影响。

Like other software engineering activities, data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction (the customer or user’s view of data). This data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system. In many software applications, the architecture of the data will have a profound influence on the architecture of the software that must process it.

数据结构一直是软件设计的重要组成部分。在程序组件级别,数据结构和操作它们所需的相关算法的设计对于创建高质量应用程序至关重要。在应用程序级别,将数据模型(作为需求工程的一部分派生)转换为数据库对于实现系统的业务目标至关重要。在业务层面,将存储在不同数据库中的信息收集起来并重新组织成“数据仓库”,从而实现数据挖掘或知识发现,从而对业务本身的成功产生影响。在每种情况下,数据设计都起着重要作用。第 10 章将更详细地讨论数据设计。第 175 页

The structure of data has always been an important part of software design. At the program-component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications. At the application level, the translation of a data model (derived as part of requirements engineering) into a database is pivotal to achieving the business objectives of a system. At the business level, the collection of information stored in disparate databases and reorganized into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the success of the business itself. In every case, data design plays an important role. Data design is discussed in more detail in Chapter 10.Page 175

9.4.3 架构设计元素

9.4.3 Architectural Design Elements

软件的建筑设计相当于房屋的平面图。平面图描绘了房间的整体布局;它们的大小、形状以及彼此之间的关系;以及允许进出房间的门窗。平面图让我们对房子有一个整体的看法。架构设计元素为我们提供了软件的整体视图。

The architectural design for software is the equivalent to the floor plan of a house. The floor plan depicts the overall layout of the rooms; their size, shape, and relationship to one another; and the doors and windows that allow movement into and out of the rooms. The floor plan gives us an overall view of the house. Architectural design elements give us an overall view of the software.

架构模型 [Sha15] 来自三个来源:(1) 有关要构建的软件的应用程序域的信息,(2) 特定需求模型元素,例如用例或分析类、它们的关系以及问题的协作(3) 可用的架构风格(第 10 章)和模式(第 14 章)。

The architectural model [Sha15] is derived from three sources: (1) information about the application domain for the software to be built, (2) specific requirements model elements such as use cases or analysis classes, their relationships, and collaborations for the problem at hand, and (3) the availability of architectural styles (Chapter 10) and patterns (Chapter 14).

架构设计元素通常被描述为一组互连的子系统,通常源自需求模型中的分析包。每个子系统可以具有其自己的体系结构(例如,图形用户界面可以根据用户界面的预先存在的体系结构风格来构造)。第 10 章介绍了导出架构模型特定元素的技术。

The architectural design element is usually depicted as a set of interconnected subsystems, often derived from analysis packages within the requirements model. Each subsystem may have its own architecture (e.g., a graphical user interface might be structured according to a preexisting architectural style for user interfaces). Techniques for deriving specific elements of the architectural model are presented in Chapter 10.

9.4.4 界面设计元素

9.4.4 Interface Design Elements

软件的界面设计类似于一套房屋的门、窗和外部设施的详细图纸(和规格)。门、窗和外部设施的详细图纸(和规格)告诉我们事物和信息如何进出房屋以及作为平面图一部分的房间内。软件的界面设计元素描述了信息流入和流出系统以及如何在定义为体系结构一部分的组件之间进行通信。

The interface design for software is analogous to a set of detailed drawings (and specifications) for the doors, windows, and external utilities of a house. The detailed drawings (and specifications) for the doors, windows, and external utilities tell us how things and information flow into and out of the house and within the rooms that are part of the floor plan. The interface design elements for software depict information flows into and out of a system and how it is communicated among the components defined as part of the architecture.

界面设计有三个重要元素:(1)用户界面(UI);(2)外部接口;其他系统、设备、网络或其他信息生产者或消费者;(3)各种设计组件之间的内部接口。这些接口设计元素允许软件进行外部通信,并支持填充软件架构的组件之间的内部通信和协作。

There are three important elements of interface design: (1) the user interface (UI); (2) external interfaces; to other systems, devices, networks, or other producers or consumers of information; and (3) internal interfaces between various design components. These interface design elements allow the software to communicate externally and enable internal communication and collaboration among the components that populate the software architecture.

UI 设计(越来越多地称为UX 或用户体验设计)是一项主要的软件工程操作,将在第 12 章中详细讨论。UX 设计的重点是确保 UI 设计的可用性。可用的设计包含精心选择的美学元素(例如,布局、颜色、图形、信息布局)、人体工程学元素(例如,交互机制、信息放置、隐喻、UI 导航)和技术元素(例如,UX 模式、可重用组件) 。一般来说,UI 是整个应用程序架构中的一个独特的子系统,旨在为最终用户提供令人满意的用户体验。

UI design (increasingly called UX or user experience design) is a major software engineering action and is considered in detail in Chapter 12. UX design focuses on ensuring the usability of the UI design. A usable design incorporates carefully chosen aesthetic elements (e.g., layout, color, graphics, information layout), ergonomic elements (e.g., interaction mechanisms, information placement, metaphors, UI navigation), and technical elements (e.g., UX patterns, reusable components). In general, the UI is a unique subsystem within the overall application architecture designed to provide the end user with a satisfying user experience.

外部接口的设计需要有关向其发送或接收信息的实体的明确信息。在每种情况下,这些信息都应该在需求工程(第 7 章)期间收集,并在接口设计开始后进行验证。10外部接口的设计应包含错误检查和适当的安全功能。

The design of external interfaces requires definitive information about the entity to which information is sent or received. In every case, this information should be collected during requirements engineering (Chapter 7) and verified once the interface design commences.10 The design of external interfaces should incorporate error checking and appropriate security features.

第 176 页内部接口的设计与组件级设计紧密结合(第11章)。分析类的设计实现表示所有操作以及实现各个类中的操作之间的通信和协作所需的消息传递方案。每条消息的设计必须能够满足必要的信息传输和所请求操作的特定功能要求。

Page 176The design of internal interfaces is closely aligned with component-level design (Chapter 11). Design realizations of analysis classes represent all operations and the messaging schemes required to enable communication and collaboration between operations in various classes. Each message must be designed to accommodate the requisite information transfer and the specific functional requirements of the operation that has been requested.

在某些情况下,接口的建模方式与类的建模方式非常相似。接口是一组操作,它描述类的某些行为并提供对这些操作的访问。

In some cases, an interface is modeled in much the same way as a class. An interface is a set of operations that describes some part of the behavior of a class and provides access to these operations.

例如,SafeHome安全功能利用控制面板,该控制面板允许房主控制安全功能的某些特征。在系统的高级版本中,控制面板功能可以通过移动平台(例如智能手机或平板电脑)实现,如图 9.5所示。

For example, the SafeHome security function makes use of a control panel that allows a homeowner to control certain features of the security function. In an advanced version of the system, control panel functions may be implemented via a mobile platform (e.g., smartphone or tablet) and are represented in Figure 9.5.

9.5 控制面板的界面表示

Figure 9.5 Interface representation for ControlPanel

9.4.5 组件级设计元素

9.4.5 Component-Level Design Elements

软件的组件级设计相当于房屋中每个房间的一组详细图纸(和规格)。这些图纸描绘了每个房间内的布线和管道、电源插座和墙壁开关、水龙头、水槽、淋浴、浴缸、排水管、橱柜和壁橱的位置,以及与房间相关的所有其他细节。

The component-level design for software is the equivalent to a set of detailed drawings (and specifications) for each room in a house. These drawings depict wiring and plumbing within each room, the location of electrical receptacles and wall switches, faucets, sinks, showers, tubs, drains, cabinets, and closets, and every other detail associated with a room.

软件的组件级设计充分描述了每个软件组件的内部细节。为了实现这一点,组件级设计定义了所有本地数据对象的数据结构、组件内发生的所有处理的算法细节以及允许访问所有组件操作(行为)的接口。

The component-level design for software fully describes the internal detail of each software component. To accomplish this, the component-level design defines data structures for all local data objects and algorithmic detail for all processing that occurs within a component and an interface that allows access to all component operations (behaviors).

在面向对象的软件工程背景下,组件以 UML 图表形式表示,如图9.6所示。在此图中,显示了一个名为SensorManagement的组件(SafeHome安全功能的一部分)。虚线箭头将组件连接到分配给它的名为Sensor的类。SensorManagement组件执行与SafeHome传感器相关的所有功能包括监控和配置它们。第 11 章将进一步讨论组件设计。

Within the context of object-oriented software engineering, a component is represented in UML diagrammatic form, as shown in Figure 9.6. In this figure, a component named SensorManagement (part of the SafeHome security function) is represented. A dashed arrow connects the component to a class named Sensor that is assigned to it. The SensorManagement component performs all functions associated with SafeHome sensors including monitoring and configuring them. Further discussion of component design is presented in Chapter 11.

图9.6 UML 组件图

Figure 9.6 A UML component diagram

组件的设计细节可以在许多不同的抽象级别上建模。UML 活动图可用于表示处理逻辑。组件的算法结构细节可以使用伪代码(第11章中描述的类似编程语言的表示)或某种其他图表形式(例如流程图)来表示。数据结构细节通常使用伪代码或用于实现的编程语言来建模。

The design details of a component can be modeled at many different levels of abstraction. A UML activity diagram can be used to represent processing logic. Algorithmic structure details for a component can be represented using either pseudocode (a programming languagelike representation described in Chapter 11) or some other diagrammatic form (e.g., flowchart). Data structure details are usually modeled using pseudocode or the programming language to be used for implementation.

9.4.6 部署级设计元素

9.4.6 Deployment-Level Design Elements

部署级设计元素指示如何在支持软件的物理计算环境中分配软件功能和子系统。例如,SafeHome产品的元素被配置为在三个主要计算环境(移动设备)中运行,在本例中为 PC、SafeHome控制面板和位于 CPI Corp. 的服务器(提供基于 Internet 的访问)系统)。

Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software. For example, the elements of the SafeHome product are configured to operate within three primary computing environments—a mobile device—in this case a PC, the SafeHome control panel, and a server housed at CPI Corp. (providing Internet-based access to the system).

在设计过程中,开发并完善了 UML 部署图,如图9.7所示。图中显示了三个计算环境(在完整的设计中,将包括更多细节:传感器、摄像头以及移动平台提供的功能)。指示了每个计算元件内容纳的子系统(功能)。例如,个人计算机包含实现安全、监视、家庭管理和通信功能的子系统。此外,还设计了外部访问子系统来管理从外部源访问SafeHome系统的所有尝试。每个子系统都将被详细说明以指示它实现的组件。第 177 页

During design, a UML deployment diagram is developed and then refined, as shown in Figure 9.7. In the figure, three computing environments are shown (in the full design there would be more details included: sensors, cameras, and the functionality delivered by mobile platforms). The subsystems (functionality) housed within each computing element are indicated. For example, the personal computer houses subsystems that implement security, surveillance, home management, and communications features. In addition, an external access subsystem has been designed to manage all attempts to access the SafeHome system from an external source. Each subsystem would be elaborated to indicate the components that it implements.Page 177

图9.7 UML 部署

Figure 9.7 A UML deployment diagram

图 9.7所示的图是描述符形式的。这意味着部署图显示了计算环境,但没有明确指示配置详细信息。例如,“个人计算机”没有进一步标识。它可以是 Mac、基于 Windows 的 PC、Linux 机或具有相关操作系统的移动平台。当在设计的后期阶段或施工开始时以实例形式重新访问部署图时,会提供这些详细信息。部署的每个实例(特定的、命名的硬件配置)都会被识别。

The diagram shown in Figure 9.7 is in descriptor form. This means that the deployment diagram shows the computing environment but does not explicitly indicate configuration details. For example, the “personal computer” is not further identified. It could be a Mac, a Windows-based PC, a Linux box, or a mobile platform with its associated operating system. These details are provided when the deployment diagram is revisited in instance form during the latter stages of design or as construction begins. Each instance of the deployment (a specific, named hardware configuration) is identified.

第 179 页

Page 179

9.5 总结

9.5 Summary

软件设计随着需求工程的第一次迭代结束而开始。软件设计的目的是应用一组原则、概念和实践来开发高质量的系统或产品。设计的目标是创建一个软件模型,该模型将正确实现所有客户需求并为使用它的人带来乐趣。软件设计人员必须筛选多种设计方案,并集中找到最适合项目利益相关者需求的解决方案。

Software design commences as the first iteration of requirements engineering concludes. The intent of software design is to apply a set of principles, concepts, and practices that lead to the development of a high-quality system or product. The goal of design is to create a model of software that will implement all customer requirements correctly and bring delight to those who use it. Software designers must sift through many design alternatives and converge on a solution that best suits the needs of project stakeholders.

设计过程从软件的“大局”视图转向定义实现系统所需的细节的更窄视图。该过程首先关注架构。定义子系统,建立子系统之间的通信机制,识别组件,并开发每个组件的详细描述。此外,外部、内部和用户界面也是同时设计的。

The design process moves from a “big picture” view of software to a narrower view that defines the detail required to implement a system. The process begins by focusing on architecture. Subsystems are defined, communication mechanisms among subsystems are established, components are identified, and a detailed description of each component is developed. In addition, external, internal, and user interfaces are designed at the same time.

设计概念在软件工程工作的前 60 年中不断发展。它们描述了计算机软件应该存在的属性,无论选择什么软件工程过程、应用的设计方法或使用的编程语言。从本质上讲,设计概念强调需要抽象作为创建可重用软件组件的机制;架构作为更好地理解系统整体结构的一种方式的重要性;基于模式的工程作为一种设计具有经过验证的功能的软件技术的好处;关注点分离和有效模块化的价值作为使软件更易于理解、更可测试和更可维护的一种方式;信息隐藏作为一种减少错误发生时副作用传播的机制的后果;功能独立性作为构建有效模块的标准的影响;使用细化作为设计机制;应用重构来优化衍生的设计;面向对象类的重要性以及与其相关的特征;需要使用抽象来减少组件之间的耦合;以及测试设计的重要性。

Design concepts have evolved over the first 60 years of software engineering work. They describe attributes of computer software that should be present regardless of the software engineering process that is chosen, the design methods that are applied, or the programming languages that are used. In essence, design concepts emphasize the need for abstraction as a mechanism for creating reusable software components; the importance of architecture as a way to better understand the overall structure of a system; the benefits of pattern-based engineering as a technique for designing software with proven capabilities; the value of separation of concerns and effective modularity as a way to make software more understandable, more testable, and more maintainable; the consequences of information hiding as a mechanism for reducing the propagation of side effects when errors do occur; the impact of functional independence as a criterion for building effective modules; the use of refinement as a design mechanism; the application of refactoring for optimizing the design that is derived; the importance of object-oriented classes and the characteristics that are related to them; the need to use abstraction to reduce coupling between components; and the importance of design for testing.

设计模型包含四个不同的元素。随着这些元素中每一个的发展,设计的更完整的视图就会逐渐形成。体系结构元素使用从应用程序域、需求模型以及可用的模式和样式目录派生的信息来派生软件、其子系统和组件的完整结构表示。界面设计元素对外部和内部界面以及用户界面进行建模。组件级元素定义填充架构的每个模块(组件)。最后,部署级设计元素将架构、其组件和接口分配给容纳软件的物理配置。

The design model encompasses four different elements. As each of these elements is developed, a more complete view of the design evolves. The architectural element uses information derived from the application domain, the requirements model, and available catalogs for patterns and styles to derive a complete structural representation of the software, its subsystems, and components. Interface design elements model external and internal interfaces and the user interface. Component-level elements define each of the modules (components) that populate the architecture. Finally, deployment-level design elements allocate the architecture, its components, and the interfaces to the physical configuration that will house the software.

问题与思考点

Problems and Points to Ponder

9.1. 当你“编写”程序时,你是在设计软件吗?软件设计与编码有何不同?

9.1. Do you design software when you “write” a program? What makes software design different from coding?

9.2. 如果软件设计不是程序(事实上也不是),那么它是什么?

9.2. If a software design is not a program (and it isn’t), then what is it?

9.3. 我们如何评估软件设计的质量?

9.3. How do we assess the quality of a software design?

9.4. 用你自己的话描述软件架构。

9.4. Describe software architecture in your own words.

9.5。用你自己的话描述关注点分离。是否存在“分而治之”策略可能不合适的情况?这种情况会如何影响模块化的争论?

9.5. Describe separation of concerns in your own words. Is there a case when a “divide and conquer” strategy may not be appropriate? How might such a case affect the argument for modularity?

第180页9.6. 讨论作为有效模块化属性的信息隐藏概念与模块独立性概念之间的关系。

Page 1809.6. Discuss the relationship between the concept of information hiding as an attribute of effective modularity and the concept of module independence.

9.7. 耦合和软件可移植性的概念有何关系?提供示例来支持您的讨论。

9.7. How are the concepts of coupling and software portability related? Provide examples to support your discussion.

9.8. 应用“逐步细化方法”为以下一个或多个程序开发三个不同级别的程序抽象: (1) 开发一个支票编写器,在给定数字美元金额的情况下,它将以支票上通常需要的文字打印金额。(2) 迭代求解超越方程的根。(3) 为操作系统开发一个简单的任务调度算法。

9.8. Apply a “stepwise refinement approach” to develop three different levels of procedural abstractions for one or more of the following programs: (1) Develop a check writer that, given a numeric dollar amount, will print the amount in words normally required on a check. (2) Iteratively solve for the roots of a transcendental equation. (3) Develop a simple task-scheduling algorithm for an operating system.

9.9. 重构是否意味着迭代地修改整个设计?如果不是,那意味着什么?

9.9. Does refactoring mean that you modify the entire design iteratively? If not, what does it mean?

9.10。简要描述设计模型的四个要素。

9.10. Briefly describe each of the four elements of the design model.

1对软件设计哲学进一步感兴趣的读者可能会对 Philippe Kruchen 对“后现代”设计的有趣讨论感兴趣 [Kru05]。

1 Those readers with further interest in the philosophy of software design might have interest in Philippe Kruchen’s intriguing discussion of “postmodern” design [Kru05].

2对于较小的系统,有时可以线性开发设计。

2 For smaller systems, design can sometimes be developed linearly.

3第 23 章中讨论的质量因素可以帮助审核小组评估质量。

3 The quality factors discussed in Chapter 23 can assist the review team as it assesses quality.

4此时您可能会考虑查看第 16 章。技术评审是设计过程的关键部分,也是实现设计质量的重要机制。

4 You might consider looking ahead to Chapter 16 at this time. Technical reviews are a critical part of the design process and are an important mechanism for achieving design quality.

5可变性密集型系统是指可能需要根据运行时环境或软件产品系列的变化进行自我修改的系统,这些变化是由于从现有软件产品构建专门的产品变体的产品线工程实践而产生的。

5 Variability-intensive systems refers to systems that may be required to be self-modifying based on changes in the run-time environment or families of software products resulting from product line engineering practices for building specialized product variants out of existing software products.

6然而,应该注意的是,如果过程抽象隐含的功能保持不变,则一组操作可以替换为另一组操作。因此,如果相机是自动的并连接到自动触发移动设备上警报的传感器,那么实施使用所需的步骤将发生巨大变化。

6 It should be noted, however, that one set of operations can be replaced with another, if the function implied by the procedural abstraction remains the same. Therefore, the steps required to implement use would change dramatically if the camera were automatic and attached to a sensor that automatically triggered an alert on your mobile device.

7这些具有共同功能的相关软件产品系列称为软件产品线

7 These families of related software products sharing common features are called software product lines.

8描述德墨忒尔定律的一种不太正式的方式是“每个单元只能与其朋友交谈;不要和陌生人说话。”

8 A less formal way of stating the Law of Demeter is “Each unit should only talk to its friends; don’t talk to strangers.”

9附录 1 提供了有关基本 UML 概念和符号的教程。

9 Appendix 1 provides a tutorial on basic UML concepts and notation.

10界面特性会随时间而变化。因此,设计者应确保接口规范的准确和完整。

10 Interface characteristics can change with time. Therefore, a designer should ensure that the specification for the interface is accurate and complete.

第 181 页

Page 181

章节

chapter

10建筑设计——推荐方法

10 Architectural Design—A Recommended Approach

设计被描述为一个多步骤的过程,其中数据和程序结构、界面特征和程序细节的表示是根据信息需求综合的。正如我们在第 9 章中提到的,设计是信息驱动的。软件设计方法源自对分析模型的三个领域中每一个领域的考虑。在考虑数据、功能和行为领域时做出的决策可以作为创建软件架构设计的指南。

Design has been described as a multistep process in which representations of data and program structure, interface characteristics, and procedural detail are synthesized from information requirements. As we noted in Chapter 9, design is information driven. Software design methods are derived from consideration of each of the three domains of the analysis model. The decisions made while considering the data, functional, and behavioral domains serve as guides for the creation of the software architectural design.

第182页Philippe Kruchten、Grady Booch、Kurt Bittner 和 Rich Reitman [Mic09] 认为软件架构识别系统的“结构元素及其接口”,以及各个组件和子系统的“行为”。他们写道,架构设计的工作是创建系统和软件的“连贯的、精心规划的表示”。

Page 182Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman [Mic09] suggest that software architecture identifies a system’s “structural elements and their interfaces,” along with the “behavior” of individual components and subsystems. They write that the job of architectural design is to create “coherent, well-planned representations” of the system and software.

本章介绍了创建设计模型的数据和架构层的此类表示的方法。目的是为架构设计的推导提供一种系统的方法——构建软件的初步蓝图。

Methods to create such representations of the data and architectural layers of the design model are presented in this chapter. The objective is to provide a systematic approach for the derivation of the architectural design—the preliminary blueprint from which software is constructed.

10.1 软件架构

10.1 Software Architecture

Shaw 和 Garlan [Sha15] 在他们关于该主题的里程碑式著作中指出,自计算机编程诞生以来,“软件系统就已经有了架构,程序员一直负责模块之间的交互以及组合的全局属性。 ” 如今,有效的软件架构及其明确的表示和设计已成为软件工程的主导主题。

In their landmark book on the subject, Shaw and Garlan [Sha15] argue that since the earliest days of computer programming, “software systems have had architectures, and programmers have been responsible for the interactions among the modules and the global properties of the assemblage.” Today, effective software architecture and its explicit representation and design have become dominant themes in software engineering.

10.1.1 什么是架构?

10.1.1 What Is Architecture?

当您考虑建筑物的架构时,您会想到许多不同的属性。在最简单的层面上,您会考虑物理结构的整体形状。但实际上,建筑的意义远不止于此。这是将建筑物的各个组成部分整合在一起形成一个有凝聚力的整体的方式。这是建筑物融入环境并与附近其他建筑物相融合的方式。它是建筑物满足其既定目的并满足业主需求的程度。它是结构的美感——建筑物的视觉冲击力——以及纹理、颜色和材料的组合方式,以创造外部立面和内部“居住环境”。这是一些小细节——照明装置的设计、地板的类型、壁挂的放置;这个清单几乎是无穷无尽的。最后,它是艺术。

When you consider the architecture of a building, many different attributes come to mind. At the most simplistic level, you think about the overall shape of the physical structure. But in reality, architecture is much more. It is the manner in which the various components of the building are integrated to form a cohesive whole. It is the way in which the building fits into its environment and meshes with other buildings in its vicinity. It is the degree to which the building meets its stated purpose and satisfies the needs of its owner. It is the aesthetic feel of the structure—the visual impact of the building—and the way textures, colors, and materials are combined to create the external facade and the internal “living environment.” It is small details—the design of lighting fixtures, the type of flooring, the placement of wall hangings; the list is almost endless. And finally, it is art.

建筑也是另一回事。这是“数以千计的大大小小的决定”[Tyr05]。其中一些决策是在设计早期做出的,可能对所有其他设计行为产生深远的影响。其他的则被推迟到以后,从而消除了过度限制性的约束,这些约束可能导致架构风格的实施不佳。

Architecture is also something else. It is “thousands of decisions, both big and small” [Tyr05]. Some of these decisions are made early in design and can have a profound impact on all other design actions. Others are delayed until later, thereby eliminating overly restrictive constraints that would lead to a poor implementation of the architectural style.

就像房屋平面图只是建筑物的表示一样,软件架构表示也不是可操作的产品。相反,它是一种表示,使您能够 (1) 分析设计在满足其规定要求方面的有效性,(2) 在设计更改仍然相对容易的阶段考虑架构替代方案,以及 (3) 降低风险与软件的构建相关。

Just like the plans for a house are merely a representation of the building, the software architecture representation is not an operational product. Rather, it is a representation that enables you to (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software.

这个定义强调了“软件组件”在任何架构表示中的作用。在架构设计的背景下,软件组件可以是像程序模块或面向对象的类一样简单的东西,但它也可以扩展到包括数据库和“中间件”,以支持客户端和服务器网络的配置。组件的属性是理解组件如何与其他组件交互所必需的特征。在体系结构级别,未指定内部属性(例如,算法的细节)。组件之间的关系可以像从一个模块到另一个模块的过程调用一样简单,也可以像数据库访问协议一样复杂。第183页

This definition emphasizes the role of “software components” in any architectural representation. In the context of architectural design, a software component can be something as simple as a program module or an object-oriented class, but it can also be extended to include databases and “middleware” that enable the configuration of a network of clients and servers. The properties of components are those characteristics that are necessary to an understanding of how the components interact with other components. At the architectural level, internal properties (e.g., details of an algorithm) are not specified. The relationships between components can be as simple as a procedure call from one module to another or as complex as a database access protocol.Page 183

我们相信软件设计可以被视为某种软件架构的实例。然而,被定义为特定软件架构的一部分的元素和结构是每个设计的根源。我们建议设计应该从考虑软件架构开始。

We believe that a software design can be thought of as an instance of some software architecture. However, the elements and structures that are defined as parts of particular software architectures are the root of every design. It is our recommendation that design should begin with a consideration of the software architecture.

10.1.2 为什么架构很重要?

10.1.2 Why Is Architecture Important?

在一本专门讨论软件架构的书中,Bass 和他的同事 [Bas12] 指出了软件架构重要的三个关键原因:

In a book dedicated to software architecture, Bass and his colleagues [Bas12] identify three key reasons that software architecture is important:

  • 软件架构提供了一种促进所有利益相关者之间沟通的表示形式。

  • Software architecture provides a representation that facilitates communication among all stakeholders.

  • 该架构强调了早期的设计决策,这些决策将对后续的所有软件工程工作产生深远的影响。

  • The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows.

  • 该架构构成了系统组件如何构建和协同工作的相对较小的模型。

  • The architecture constitutes a relatively small model of how the system components are structured and work together.

架构设计模型和其中包含的架构模式是可转移的。也就是说,架构流派、风格和模式(第 10.3 节到 10.6 节)可以应用于其他系统的设计,并表示一组抽象,使软件工程师能够以可预测的方式描述架构。

The architectural design model and the architectural patterns contained within it are transferable. That is, architecture genres, styles, and patterns (Sections 10.3 through 10.6) can be applied to the design of other systems and represent a set of abstractions that enable software engineers to describe architecture in predictable ways.

在定义软件架构时做出正确的决策对于软件产品的成功至关重要。软件架构设定了系统的结构并决定了其质量[Das15]。

Making good decisions while defining the software architecture is critical to the success of a software product. The software architecture sets the structure of the system and determines its quality [Das15].

10.1.3 架构描述

10.1.3 Architectural Descriptions

我们每个人对建筑这个词的含义都有一个心理印象。这意味着不同的利益相关者将从不同的角度看待给定的软件架构,这些角度是由不同的关注点驱动的。这意味着架构描述实际上是反映系统不同视图的一组工作产品。

Each of us has a mental image of what the word architecture means. The implication is that different stakeholders will see a given software architecture from different viewpoints that are driven by different sets of concerns. This implies that an architectural description is actually a set of work products that reflect different views of the system.

Smolander、Rossi 和 Purao [Smo08] 已经确定了多个隐喻,代表利益相关者用来理解术语软件架构的同一架构的不同视图。蓝图隐喻对于编写程序来实现系统的利益相关者来说似乎是最熟悉的。开发人员将架构描述视为将显式信息从架构师传递到设计师再到负责生产系统组件的软件工程师的一种手段。

Smolander, Rossi, and Purao [Smo08] have identified multiple metaphors, representing different views of the same architecture that stakeholders use to understand the term software architecture. The blueprint metaphor seems to be most familiar to the stakeholders who write programs to implement a system. Developers regard architecture descriptions as a means of transferring explicit information from architects to designers to software engineers charged with producing the system components.

语言隐喻将架构视为利益相关者群体之间沟通的促进者。这种观点受到高度关注客户的利益相关者(例如经理或营销专家)的青睐。架构描述需要简洁且易于理解,因为它构成了协商的基础,特别是在确定系统边界时。

The language metaphor views architecture as a facilitator of communication across stakeholder groups. This view is preferred by stakeholders with a high customer focus (e.g., managers or marketing experts). The architectural description needs to be concise and easy to understand because it forms the basis for negotiation, particularly in determining system boundaries.

第184页决策隐喻将架构表示为决策的产物,涉及成本、可用性、可维护性和性能等属性之间的权衡,这些属性对所设计的系统具有资源影响。项目经理等利益相关者将架构决策视为分配项目资源和任务的基础。这些决策可能会影响任务的顺序并塑造软件团队的结构。

Page 184The decision metaphor represents architecture as the product of decisions involving trade-offs among properties such as cost, usability, maintainability, and performance that have resource consequences for the system being designed. Stakeholders such as project managers view architectural decisions as the basis for allocating project resources and tasks. These decisions may affect the sequence of tasks and shape the structure of the software team.

文学隐喻用于记录过去构建的架构解决方案。该视图支持工件的构建以及设计人员和软件维护人员之间的知识转移。它还支持关注组件和设计重用的利益相关者。

The literature metaphor is used to document architectural solutions constructed in the past. This view supports the construction of artifacts and the transfer of knowledge between designers and software maintenance staff. It also supports stakeholders whose concern is reuse of components and designs.

架构描述(AD)表示使用多个视图的系统,其中每个视图都是“从一组相关的[利益相关者]关注点的角度来看整个系统的表示”。IEEE 计算机协会标准 IEEE-Std-42010:2011(E),系统和软件工程 - 体系结构描述[IEE11],描述了体系结构观点、体系结构框架和体系结构描述语言的使用,作为编纂约定和通用规范的方法。架构描述的实践。

An architectural description (AD) represents a system using multiple views, where each view is “a representation of a whole system from the perspective of a related set of [stakeholder] concerns.” The IEEE Computer Society standard IEEE-Std-42010:2011(E), Systems and software engineering—Architectural description [IEE11], describes the use of architecture viewpoints, architecture frameworks, and architecture description languages as a means of codifying the conventions and common practices for architectural description.

10.1.4 架构决策

10.1.4 Architectural Decisions

作为架构描述的一部分开发的每个视图都解决了特定的利益相关者关注的问题。为了开发每个视图(以及整个体系结构描述),系统架构师会考虑各种替代方案,并最终决定最能满足关注点的特定体系结构功能。架构决策本身可以被认为是架构的一种视图。做出决策的原因可以深入了解系统的结构及其与利益相关者关注点的一致性。

Each view developed as part of an architectural description addresses a specific stakeholder concern. To develop each view (and the architectural description as a whole), the system architect considers a variety of alternatives and ultimately decides on the specific architectural features that best meet the concern. Architectural decisions themselves can be considered to be one view of the architecture. The reasons that decisions were made provide insight into the structure of a system and its conformance to stakeholder concerns.

作为系统架构师,您可以使用侧栏中建议的模板来记录每个主要决策。通过这样做,您可以为您的工作提供理由并建立历史记录,该记录在必须进行设计修改时非常有用。对于敏捷开发人员来说,轻量级架构决策记录(ADR) 可能只包含标题、上下文(假设和约束)、决策(解决方案)、状态(建议接受、拒绝)和结果(影响)[Nyg11]。

As a system architect, you can use the template suggested in the sidebar to document each major decision. By doing this, you provide a rationale for your work and establish a historical record that can be useful when design modifications must be made. For agile developers, a lightweight architectural decision record (ADR) might simply contain a title, a context (assumptions and constraints), the decision (resolution), status (proposed accepted rejected), and consequences (implications) [Nyg11].

Grady Booch [Boo11a] 写道,当着手构建创新产品时,软件工程师常常感到有必要立即投入,构建东西,修复不起作用的东西,改进起作用的东西,然后重复这个过程。这样做几次后,他们开始认识到应该首先定义架构,并且必须明确说明与架构选择相关的决策。在构建新产品之前可能无法预测正确的选择。然而,如果创新者在现场测试原型后发现架构决策值得重复,那么此类产品的主导设计1可能会开始出现。如果不记录哪些有效、哪些无效,软件工程师就很难决定何时进行创新以及何时使用以前创建的架构。第185页

Grady Booch [Boo11a] writes that when setting out to build an innovative product, software engineers often feel compelled to plunge right in, build stuff, fix what doesn’t work, improve what does work, and then repeat the process. After doing this a few times, they begin to recognize that the architecture should be defined first and decisions associated with architectural choices must be stated explicitly. It may not be possible to predict the right choices before building a new product. However, if innovators find that architectural decisions are worth repeating after testing their prototypes in the field, then a dominant design1 for this type of product may begin to emerge. Without documenting what worked and what did not, it is hard for software engineers to decide when to innovate and when to use previously created architecture.Page 185

10.2 敏捷性和架构

10.2 Agility and Architecture

一些敏捷开发人员认为,架构设计等同于“预先进行大设计”。在他们看来,这会导致不必要的文档和不必要的功能的实现。然而,大多数敏捷开发人员都会同意[Fal10],当系统复杂时(即,当产品有大量需求、大量利益相关者或大量全球用户时),关注软件架构非常重要。因此,将新的架构设计实践集成到敏捷流程模型中非常重要。

The view of some agile developers is that architectural design is equated with “big design upfront.” In their view, this leads to unnecessary documentation and the implementation of unnecessary features. However, most agile developers would agree [Fal10] that it is important to focus on software architecture when a system is complex (i.e., when a product has a large number of requirements, lots of stakeholders, or a large number of global users). For this reason, it is important to integrate new architectural design practices into agile process models.

为了做出早期架构决策并避免因选择错误架构而纠正质量问题所需的返工,敏捷开发人员需要预测从收集的用户故事集合中出现的架构元素 2 和隐含结构(第 7 章)。通过创建架构原型(例如,行走的骨架)并开发明确的架构工作产品以将正确的信息传达给必要的利益相关者,敏捷团队可以满足架构设计的需求。第186页

To make early architectural decisions and avoid the rework required to correct the quality problems encountered when the wrong architecture is chosen, agile developers need to anticipate architectural elements2 and implied structure that emerges from the collection of user stories gathered (Chapter 7). By creating an architectural prototype (e.g., a walking skeleton) and developing explicit architectural work products to communicate the right information to the necessary stakeholders, an agile team can satisfy the need for architectural design.Page 186

使用称为故事板的技术,架构师向项目贡献架构用户故事,并与产品负责人合作,在规划“冲刺”(工作单元)时,根据业务用户故事确定架构故事的优先级。架构师在冲刺期间与团队合作,以确保不断发展的软件继续表现出非功能性产品需求所定义的高架构质量。如果质量很高,团队就可以独自继续开发。如果没有,架构师将在冲刺期间加入团队。冲刺完成后,架构师会审查工作原型的质量,然后团队在正式的冲刺审查中将其呈现给利益相关者。运行良好的敏捷项目在每个冲刺中都利用迭代工作产品交付(包括架构文档)。审查每个冲刺中出现的工作产品和代码是架构审查的一种有用形式。

Using a technique called storyboarding, the architect contributes architectural user stories to the project and works with the product owner to prioritize the architectural stories with the business user stories as “sprints” (work units) are planned. The architect works with the team during the sprint to ensure that the evolving software continues to show high architectural quality as defined by the nonfunctional product requirements. If quality is high, the team is left alone to continue development on its own. If not, the architect joins the team for the duration of the sprint. After the sprint is completed, the architect reviews the working prototype for quality before the team presents it to the stakeholders in a formal sprint review. Well-run agile projects make use of iterative work product delivery (including architectural documentation) with each sprint. Reviewing the work products and code as it emerges from each sprint is a useful form of architectural review.

责任驱动架构(RDA) 是一个重点关注何时、如何以及由谁应该在项目团队中做出架构决策的过程。这种方法还强调架构师作为仆人领导者而不是专制决策者的角色,并且与敏捷哲学相一致。架构师充当促进者,重点关注开发团队如何工作来满足利益相关者的非技术问题(例如,业务、安全性、可用性)。

Responsibility-driven architecture (RDA) is a process that focuses on when, how, and who should make the architectural decisions on a project team. This approach also emphasizes the role of architect as being a servant-leader rather than an autocratic decision maker and is consistent with the agile philosophy. The architect acts as facilitator and focuses on how the development team works to accommodate stakeholder’s nontechnical concerns (e.g., business, security, usability).

随着新需求的出现,敏捷团队通常可以自由地进行系统更改。架构师希望确保架构的重要部分得到仔细考虑,并且开发人员已咨询适当的利益相关者。这两个问题都可以通过使用一种称为渐进式签核的做法来满足,其中随着每个后续原型的完成,不断发展的产品被记录并得到批准[Bla10]。

Agile teams usually have the freedom to make system changes as new requirements emerge. Architects want to make sure that the important parts of the architecture were carefully considered and that developers have consulted the appropriate stakeholders. Both concerns may be satisfied by making use of a practice called progressive sign-off in which the evolving product is documented and approved as each successive prototype is completed [Bla10].

使用与敏捷理念兼容的流程为监管机构和审计人员提供可验证的签核,而不会妨碍授权的敏捷团队做出所需的决策。项目结束时,团队拥有一套完整的工作产品,并且随着架构的发展,已经对其质量进行了审查。

Using a process that is compatible with the agile philosophy provides verifiable sign-off for regulators and auditors, without preventing the empowered agile teams from making the decisions needed. At the end of the project, the team has a complete set of work products and the architecture has been reviewed for quality as it evolved.

第187页

Page 187

10.3 架构风格

10.3 Architectural Styles

当建筑商使用“中心大厅殖民地”一词来描述房屋时,大多数熟悉美国房屋的人都能够对房屋的外观和平面图可能是什么样子产生一个总体印象。建造者使用建筑风格作为描述机制来区分房屋与其他风格(例如,A 形框架、凸起牧场、科德角)。但更重要的是,建筑风格也是建筑的模板。房子的更多细节必须被定义,它的最终尺寸必须被指定,定制的功能可以被添加,建筑材料将被确定,但风格——“中心大厅殖民地”——指导建造者的工作。

When a builder uses the phrase “center hall colonial” to describe a house, most people familiar with houses in the United States will be able to conjure a general image of what the house will look like and what the floor plan is likely to be. The builder has used an architectural style as a descriptive mechanism to differentiate the house from other styles (e.g., A-frame, raised ranch, Cape Cod). But more important, the architectural style is also a template for construction. Further details of the house must be defined, its final dimensions must be specified, customized features may be added, building materials are to be determined, but the style—a “center hall colonial”—guides the builder in his work.

为基于计算机的系统构建的软件也表现出多种架构风格之一。每种风格描述了一个系统类别,其中包括(1)执行系统所需功能的一组组件(例如数据库、计算模块),(2)一组能够实现系统之间“通信、协调和合作”的连接器。组件,(3) 定义如何集成组件以形成系统的约束,以及 (4) 语义模型,使设计人员能够通过分析系统组成部分的已知属性来理解系统的整体属性 [Bas12]。

The software that is built for computer-based systems also exhibits one of many architectural styles. Each style describes a system category that encompasses (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts [Bas12].

架构风格是强加于整个系统设计的转变。目的是为系统的所有组件建立一个结构。在要重构现有架构的情况下(第 27 章),架构风格的强加将导致软件结构的根本变化,包括组件功能的重新分配 [Bos00]。

An architectural style is a transformation that is imposed on the design of an entire system. The intent is to establish a structure for all components of the system. In the case where an existing architecture is to be refactored (Chapter 27), the imposition of an architectural style will result in fundamental changes to the structure of the software including a reassignment of the functionality of components [Bos00].

架构模式与架构风格一样,都会对架构的设计带来转变。然而,模式在许多基本方面与风格不同:(1) 模式的范围不太广泛,专注于架构的一个方面而不是整个架构,(2) 模式强加了一条规则在架构上,描述软件如何在基础设施级别处理其功能的某些方面(例如,并发)[Bos00],以及(3)架构模式(第 10.3.2 节)倾向于解决以下上下文中的特定行为问题:架构(例如,实时应用程序如何处理同步或中断)。模式可以与架构风格结合使用来塑造系统的整体结构。

An architectural pattern, like an architectural style, imposes a transformation on the design of an architecture. However, a pattern differs from a style in a number of fundamental ways: (1) the scope of a pattern is less broad, focusing on one aspect of the architecture rather than the architecture in its entirety, (2) a pattern imposes a rule on the architecture, describing how the software will handle some aspect of its functionality at the infrastructure level (e.g., concurrency) [Bos00], and (3) architectural patterns (Section 10.3.2) tend to address specific behavioral issues within the context of the architecture (e.g., how real-time applications handle synchronization or interrupts). Patterns can be used in conjunction with an architectural style to shape the overall structure of a system.

10.3.1 建筑风格的简要分类

10.3.1 A Brief Taxonomy of Architectural Styles

尽管在过去 60 年里已经创建了数百万个基于计算机的系统,但绝大多数都可以归类为相对少数的架构风格之一。

Although millions of computer-based systems have been created over the past 60 years, the vast majority can be categorized into one of a relatively small number of architectural styles.

以数据为中心的架构。数据存储(例如,文件或数据库)驻留在该架构的中心,并被更新、添加、删除或以其他方式修改存储内的数据的其他组件频繁地访问。图 10.1展示了典型的以数据为中心的风格。客户端软件访问中央存储库。在某些情况下,数据存储库是被动的。也就是说,客户端软件独立于对数据的任何更改或其他客户端软件的操作来访问数据。这种方法的一种变体将存储库转变为“黑板”,当客户端感兴趣的数据发生变化时,它会向客户端软件发送通知。

Data-Centered Architectures. A data store (e.g., a file or database) resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store. Figure 10.1 illustrates a typical data-centered style. Client software accesses a central repository. In some cases, the data repository is passive. That is, client software accesses the data independent of any changes to the data or the actions of other client software. A variation on this approach transforms the repository into a “blackboard” that sends notifications to client software when data of interest to the client changes.

图10.1 数据为中心的架构

Figure 10.1 Data-centered architecture

以数据为中心的架构促进可集成性[Bas12]。也就是说,可以更改现有组件并将新的客户端组件添加到体系结构中,而无需关心其他客户端(因为客户端组件独立运行)。另外,可以使用黑板机制在客户端之间传递数据(即,黑板组件用于协调客户端之间的信息传输)。客户端组件独立执行进程。

Data-centered architectures promote integrability [Bas12]. That is, existing components can be changed and new client components added to the architecture without concern about other clients (because the client components operate independently). In addition, data can be passed among clients using the blackboard mechanism (i.e., the blackboard component serves to coordinate the transfer of information between clients). Client components independently execute processes.

第188页数据流架构。当输入数据通过一系列计算或操作组件转换为输出数据时,应用这种架构。管道和过滤器模式(图 10.2)具有一组称为过滤器的组件,它们通过管道连接,将数据从一个组件传输到下一个组件。每个过滤器独立于上游和下游组件工作,被设计为期望某种形式的数据输入,并产生指定形式的数据输出(到下一个过滤器)。然而,过滤器不需要了解其相邻过滤器的工作原理。

Page 188Data-Flow Architectures. This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. A pipe-and-filter pattern (Figure 10.2) has a set of components, called filters, connected by pipes that transmit data from one component to the next. Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output (to the next filter) of a specified form. However, the filter does not require knowledge of the workings of its neighboring filters.

图10.2数据 流架构

Figure 10.2 Data-flow architecture

第189页调用和返回架构。这种架构风格使您能够实现相对容易修改和扩展的程序结构。此类别中存在两个子样式 [Bas12]:

Page 189Call-and-Return Architectures. This architectural style enables you to achieve a program structure that is relatively easy to modify and scale. Two substyles [Bas12] that exist within this category:

  • 主程序/子程序架构。这种经典的程序结构将功能分解为控制层次结构,其中“主”程序调用多个程序组件,而这些组件又可能调用其他组件。图 10.3展示了这种类型的架构。

    图10.3主程序 /子程序架构

  • Main program/subprogram architectures. This classic program structure decomposes function into a control hierarchy where a “main” program invokes several program components, which in turn may invoke still other components. Figure 10.3 illustrates an architecture of this type.

    Figure 10.3 Main program/subprogram architecture

  • 远程过程调用架构。主程序/子程序体系结构的组件分布在网络上的多台计算机上。

  • Remote procedure call architectures. The components of a main program/subprogram architecture are distributed across multiple computers on a network.

面向对象的架构。系统的组件封装了数据以及必须应用于操纵数据的操作。组件之间的通信和协调是通过消息传递来完成的。图 10.4包含一个 UML 通信图,显示了使用面向对象体系结构实现的系统登录部分的消息传递。通信图在本书的附录 1中有更详细的描述。

Object-Oriented Architectures. The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components are accomplished via message passing. Figure 10.4 contains a UML communication diagram that shows the message passing for the login portion of a system implemented using an object-oriented architecture. Communications diagrams are described in more details in Appendix 1 of this book.

图10.4 UML通信

Figure 10.4 UML communication diagram

分层架构。分层架构的基本结构如图10.5所示。定义了许多不同的层,每个层完成逐渐接近机器指令集的操作。在外层,组件为用户界面操作提供服务。在内层,组件执行操作系统接口。中间层提供实用服务和应用软件功能。

Layered Architectures. The basic structure of a layered architecture is illustrated in Figure 10.5. A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations. At the inner layer, components perform operating system interfacing. Intermediate layers provide utility services and application software functions.

图10.5 分层架构

Figure 10.5 Layered architecture

模型-视图-控制器(MVC) 架构 [Kra88] 是 Web 开发中经常使用的许多建议的移动基础架构模型之一。该模型包含所有特定于应用程序的内容和处理逻辑。该视图包含所有特定于界面的功能,并能够呈现最终用户所需的内容和处理逻辑。控制器管理对模型和视图的访问并协调它们之间的数据流MVC 架构的示意图如图10.6所示。

Model-View-Controller (MVC) architecture [Kra88] is one of a number of suggested mobile infrastructure models often used in Web development. The model contains all application-specific content and processing logic. The view contains all interface-specific functions and enables the presentation of content and processing logic required by the end user. The controller manages access to the model and the view and coordinates the flow of data between them. A schematic representation of the MVC architecture is shown in Figure 10.6.

图10.6 MVC 架构

Figure 10.6 The MVC architecture

资料来源:改编自 Jacyntho、Mark Douglas、Schwabe、Daniel 和 Rossi、Gustavo 的“An Architecture for Structuring Complex Web Applications”,2002 年,可从 http://www-di.inf.puc-rio.br/schwabe/papers 获取/OOHDMJava2%20Report.pdf

Source: Adapted from Jacyntho, Mark Douglas, Schwabe, Daniel and Rossi, Gustavo, “An Architecture for Structuring Complex Web Applications,” 2002, available at http://www-di.inf.puc-rio.br/schwabe/papers/OOHDMJava2%20Report.pdf

第 191 页参考该图,用户请求由控制器处理。控制器还根据用户请求选择适用的视图对象。一旦确定了请求的类型,行为请求就会传输到模型,模型实现功能或检索适应该请求所需的内容。模型对象可以访问存储在公司数据库中、作为本地数据存储的一部分或作为独立文件的集合的数据。模型开发的数据必须通过适当的视图对象进行格式化和组织,然后从应用程序服务器传输回基于客户端的浏览器,以便在客户的机器上显示。

Page 191Referring to the figure, user requests are handled by the controller. The controller also selects the view object that is applicable based on the user request. Once the type of request is determined, a behavior request is transmitted to the model, which implements the functionality or retrieves the content required to accommodate the request. The model object can access data stored in a corporate database, as part of a local data store, or as a collection of independent files. The data developed by the model must be formatted and organized by the appropriate view object and then transmitted from the application server back to the client-based browser for display on the customer’s machine.

这些架构风格只是可用架构风格的一小部分。3一旦需求工程揭示了要构建的系统的特征和约束,就可以选择最适合这些特征和约束的架构风格和/或模式组合。在许多情况下,可能不止一种模式是合适的,并且可以设计和评估替代的架构风格。例如,分层样式(适用于大多数系统)可以与许多数据库应用程序中的以数据为中心的体系结构相结合。第192页

These architectural styles are only a small subset of those available.3 Once requirements engineering uncovers the characteristics and constraints of the system to be built, the architectural style and/or combination of patterns that best fits those characteristics and constraints can be chosen. In many cases, more than one pattern might be appropriate and alternative architectural styles can be designed and evaluated. For example, a layered style (appropriate for most systems) can be combined with a data-centered architecture in many database applications.Page 192

选择正确的架构风格可能很棘手。现实世界的问题通常遵循多个问题框架,并且可能会产生组合架构模型。例如,WebApp 设计4中使用的模型-视图-控制器 (MVC) 架构可能被视为组合了两个问题框架(命令行为和信息显示)。在 MVC 中,最终用户的命令从浏览器窗口发送到命令处理器(控制器),命令处理器(控制器)管理对内容(模型)的访问,并指示信息呈现模型(视图)将其转换为由浏览器软件显示。

Choosing the right architecture style can be tricky. Real-world problems often follow more than one problem frame, and a combination architectural model may result. For example, the model-view-controller (MVC) architecture used in WebApp design4 might be viewed as combining two problem frames (command behavior and information display). In MVC, the end user’s command is sent from the browser window to a command processor (controller) that manages access to the content (model) and instructs the information rendering model (view) to translate it for display by the browser software.

10.3.2 架构模式

10.3.2 Architectural Patterns

随着需求模型的开发,您会注意到软件必须解决跨越整个应用程序的几个广泛问题。例如,几乎每个电子商务应用程序的需求模型都面临以下问题:我们如何向许多不同的客户提供广泛的商品,并让这些客户轻松地找到并购买我们的商品?

As the requirements model is developed, you’ll notice that the software must address several broad problems that span the entire application. For example, the requirements model for virtually every e-commerce application is faced with the following problem: How do we offer a broad array of goods to many different customers and allow those customers to find and purchase our goods easily?

需求模型还定义了必须回答该问题的上下文。例如,向消费者销售高尔夫设备的电子商务企业将与向大中型企业销售高价工业设备的电子商务企业在不同的环境中运营。此外,一系列限制和约束可能会影响您处理待解决问题的方式。

The requirements model also defines a context in which this question must be answered. For example, an e-commerce business that sells golf equipment to consumers will operate in a different context than an e-commerce business that sells high-priced industrial equipment to medium and large corporations. In addition, a set of limitations and constraints may affect the way you address the problem to be solved.

第193页架构模式解决特定上下文中以及一组限制和约束下的特定于应用程序的问题。该模式提出了一种架构解决方案,可以作为架构设计的基础。

Page 193Architectural patterns address an application-specific problem within a specific context and under a set of limitations and constraints. The pattern proposes an architectural solution that can serve as the basis for architectural design.

在本章前面,我们注意到大多数应用程序都适合特定的领域或类型,并且一种或多种架构风格可能适合该类型。例如,应用程序的整体架构风格可能是调用和返回或面向对象。但在这种风格中,您将遇到一系列常见问题,最好使用特定的架构模式来解决这些问题。第 14 章介绍了其中一些问题以及对架构模式的更完整的讨论。

Previously in this chapter, we noted that most applications fit within a specific domain or genre and that one or more architectural styles may be appropriate for that genre. For example, the overall architectural style for an application might be call and return or object oriented. But within that style, you will encounter a set of common problems that might best be addressed with specific architectural patterns. Some of these problems and a more complete discussion of architectural patterns are presented in Chapter 14.

10.3.3 组织与细化

10.3.3 Organization and Refinement

由于设计过程通常会给您留下许多架构替代方案,因此建立一组可用于评估派生的架构设计的设计标准非常重要。以下问题 [Bas12] 提供了对架构风格的深入了解:

Because the design process often leaves you with a number of architectural alternatives, it is important to establish a set of design criteria that can be used to assess an architectural design that is derived. The following questions [Bas12] provide insight into an architectural style:

控制。如何在架构内管理控制?是否存在不同的控制层次结构,如果存在,该控制层次结构中的组件的作用是什么?组件如何在系统内转移控制权?组件之间如何共享控制?控制拓扑是什么(即控制采用的几何形式)?控制是同步的,还是组件异步操作?

Control. How is control managed within the architecture? Does a distinct control hierarchy exist, and if so, what is the role of components within this control hierarchy? How do components transfer control within the system? How is control shared among components? What is the control topology (i.e., the geometric form that the control takes)? Is control synchronized, or do components operate asynchronously?

数据。组件之间如何进行数据通信?数据流是连续的,还是零星地传递到系统的数据对象?数据传输的模式是什么(即,数据是从一个组件传递到另一个组件还是数据可以在系统组件之间全局共享)?数据组件(例如黑板或存储库)是否存在?如果存在,它们的作用是什么?功能组件如何与数据组件交互?数据组件是被动的还是主动的(即数据组件是否主动与系统中的其他组件交互)?数据和控制如何在系统内交互?

Data. How are data communicated between components? Is the flow of data continuous, or are data objects passed to the system sporadically? What is the mode of data transfer (i.e., are data passed from one component to another or are data available globally to be shared among system components)? Do data components (e.g., a blackboard or repository) exist, and if so, what is their role? How do functional components interact with data components? Are data components passive or active (i.e., does the data component actively interact with other components in the system)? How do data and control interact within the system?

这些问题的答案为设计者提供了对设计质量的早期评估,并为更详细的架构分析奠定了基础。

The answers to these questions provide the designer with an early assessment of design quality and lay the foundation for more detailed analysis of the architecture.

进化过程模型(第 2 章)已经变得非常流行。这意味着软件架构可能需要随着每个产品增量的规划和实施而发展。在第9章中,我们将这个过程描述为重构——在不改变系统外部行为的情况下改进系统的内部结构。

Evolutionary process models (Chapter 2) have become very popular. This implies the software architectures may need to evolve as each product increment is planned and implemented. In Chapter 9, we described this process as refactoring—improving the internal structure of the system without changing its external behavior.

10.4 架构考虑

10.4 Architectural Considerations

Buschmann 和 Henny [Bus10a、Bus10b] 提出了几种架构考虑因素,可以在做出架构决策时为软件工程师提供指导。

Buschmann and Henny [Bus10a, Bus10b] suggest several architectural considerations that can provide software engineers with guidance as architecture decisions are made.

  • 经济。最好的软件是整洁的,并依靠抽象来减少不必要的细节。它避免了由于不必要的功能和特性而导致的复杂性。

  • Economy. The best software is uncluttered and relies on abstraction to reduce unnecessary detail. It avoids complexity due to unnecessary functions and features.

  • 第 194 页能见度。创建设计模型时,架构决策及其原因对于稍后检查模型的软件工程师来说应该是显而易见的。重要的设计和领域概念必须有效地传达。

  • Page 194Visibility. As the design model is created, architectural decisions and the reasons for them should be obvious to software engineers who examine the model later. Important design and domain concepts must be communicated effectively.

  • 间距。设计中的关注点分离(第 9 章)有时称为间距。足够的间距会导致模块化设计,但过多的间距会导致碎片化和可见性丧失。

  • Spacing. Separation of concerns (Chapter 9) in a design is sometimes referred to as spacing. Sufficient spacing leads to modular designs, but too much spacing leads to fragmentation and loss of visibility.

  • 对称。架构对称意味着系统的属性是一致且平衡的。对称设计更容易理解、理解和交流。作为体系结构对称性的一个示例,请考虑一个客户帐户对象,其生命周期由需要open()close()方法的软件体系结构直接建模。建筑对称既可以是结构对称,也可以是行为对称。

  • Symmetry. Architectural symmetry implies that a system is consistent and balanced in its attributes. Symmetric designs are easier to understand, comprehend, and communicate. As an example of architectural symmetry, consider a customer account object whose life cycle is modeled directly by a software architecture that requires both open() and close() methods. Architectural symmetry can be both structural and behavioral.

  • 紧急情况。突发的、自组织的行为和控制通常是创建可扩展、高效且经济的软件架构的关键。例如,许多实时软件应用程序是事件驱动的。这些定义系统行为的事件的顺序和持续时间是一种紧急性质。由于很难为每个可能的事件序列进行规划,因此系统架构师应该创建一个灵活的系统来适应这种紧急行为。

  • Emergence. Emergent, self-organized behavior and control are often the key to creating scalable, efficient, and economic software architectures. For example, many real-time software applications are event driven. The sequence and duration of these events that define the system’s behavior is an emergent quality. Because it is very difficult to plan for every possible sequence of events, a system architect should create a flexible system that accommodates this emergent behavior.

这些考虑因素并不是孤立存在的。他们彼此互动并受到彼此的调节。例如,间距可以通过经济性来加强和减少。可见度可以通过间距来平衡。

These considerations do not exist in isolation. They interact with each other and are moderated by each other. For example, spacing can be both reinforced and reduced by economy. Visibility can be balanced by spacing.

软件产品的架构描述在用于实现它的源代码中并不明确可见。因此,随着时间的推移进行的代码修改(例如,软件维护活动)可能会导致软件架构的缓慢侵蚀。设计师面临的挑战是为架构信息找到合适的抽象。这些抽象有可能添加结构,从而提高源代码的可读性和可维护性 [Bro10b]。

The architectural description for a software product is not explicitly visible in the source code used to implement it. As a consequence, code modifications made over time (e.g., software maintenance activities) can cause slow erosion of the software architecture. The challenge for a designer is to find suitable abstractions for the architectural information. These abstractions have the potential to add structuring that improves readability and maintainability of the source code [Bro10b].

10.5 架构决策

10.5 Architectural Decisions

有关系统架构的决策确定了关键设计问题以及所选架构解决方案背后的基本原理。系统架构决策包括软件系统组织、结构元素的选择及其预期协作所定义的接口,以及将这些元素组合成越来越大的子系统[Kru09]。此外,还可以选择架构模式、应用技术、中间件资产和编程语言。架构决策的结果会影响系统的非功能特性及其许多质量属性 [Zim11],并且可以通过开发人员注释进行记录。这些说明记录了关键的设计决策及其理由,为新项目团队成员提供参考,并作为经验教训的存储库。

Decisions about system architecture identify key design issues and the rationale behind chosen architectural solutions. System architecture decisions encompass software system organization, selection of structural elements and their interfaces as defined by their intended collaborations, and the composition of these elements into increasingly larger subsystems [Kru09]. In addition, choices of architectural patterns, application technologies, middleware assets, and programming language can also be made. The outcome of the architectural decisions influences the system’s nonfunctional characteristics and many of its quality attributes [Zim11] and can be documented with developer notes. These notes document key design decisions along with their justification, provide a reference for new project team members, and serve as a repository for lessons learned.

一般来说,软件架构实践侧重于表示和记录各个利益相关者的需求的架构视图。然而,可以定义一个跨越传统架构表示中包含的信息的多个视图的决策视图。决策视图捕获了架构设计决策及其基本原理。

In general, software architectural practice focuses on architectural views that represent and document the needs of various stakeholders. It is possible, however, to define a decision view that cuts across several views of information contained in traditional architectural representations. The decision view captures both the architecture design decisions and their rationale.

面向服务的架构决策(SOAD) 5建模 [Zim11] 是一个知识管理框架,它为捕获架构决策依赖性提供支持,从而使它们能够指导未来的开发活动。

Service-oriented architecture decision (SOAD)5 modeling [Zim11] is a knowledge management framework that provides support for capturing architectural decision dependencies in a manner that allows them to guide future development activities.

第196页SOAD指导模型包含有关在特定应用程序类型中应用架构风格时所需的架构决策的知识。它基于从采用该类型的建筑风格的已完成项目中获得的建筑信息。指导模型记录了存在设计问题和必须做出架构决策的位置,以及在从潜在替代方案中进行选择时应考虑的质量属性。包括以前软件应用程序的潜在替代解决方案(及其优点和缺点),以帮助架构师做出最佳决策。

Page 196A SOAD guidance model contains knowledge about architectural decisions required when applying an architectural style in a particular application genre. It is based on architectural information obtained from completed projects that employed the architectural style in that genre. The guidance model documents places where design problems exist and architectural decisions must be made, along with quality attributes that should be considered in selecting from among potential alternatives. Potential alternative solutions (with their pros and cons) from previous software applications are included to assist the architect in making the best decision possible.

SOAD决策模型记录了所需的架构决策,并记录了对先前项目实际做出的决策及其理由。指导模型以定制步骤提供架构决策模型,允许架构师删除不相关的问题、增强重要问题或添加新问题。决策模型可以利用多个指导模型,并在项目完成后向指导模型提供反馈。这种反馈可以通过从项目事后审查中汲取经验教训来完成。

A SOAD decision model documents both the architectural decisions required and records the decisions actually made on previous projects with their justifications. The guidance model feeds the architectural decision model in a tailoring step that allows the architect to delete irrelevant issues, enhance important issues, or add new issues. A decision model can make use of more than one guidance model and provides feedback to the guidance model after the project is completed. This feedback may be accomplished by harvesting lessons learned from project postmortem reviews.

10.6 架构设计

10.6 Architectural Design

当建筑设计开始时,必须建立上下文。为了实现这一点,描述了与软件交互的外部实体(例如,其他系统、设备、人)以及它们交互的性质。该信息通常可以从需求模型中获取。一旦对上下文进行建模并描述了所有外部软件接口,您就可以识别一组架构原型。

As architectural design begins, context must be established. To accomplish this, the external entities (e.g., other systems, devices, people) that interact with the software and the nature of their interaction are described. This information can generally be acquired from the requirements model. Once context is modeled and all external software interfaces have been described, you can identify a set of architectural archetypes.

原型是一种抽象(类似于类),代表系统行为的一个元素原型集提供了抽象的集合,如果要构造系统,则必须对这些抽象进行架构建模,但原型本身没有提供足够的实现细节。因此,设计者通过定义和细化实现每个原型的软件组件来指定系统的结构。这个过程不断迭代,直到导出完整的架构结构。

An archetype is an abstraction (similar to a class) that represents one element of system behavior. The set of archetypes provides a collection of abstractions that must be modeled architecturally if the system is to be constructed, but the archetypes themselves do not provide enough implementation detail. Therefore, the designer specifies the structure of the system by defining and refining software components that implement each archetype. This process continues iteratively until a complete architectural structure has been derived.

当软件工程师创建有意义的架构图时,必须提出并回答几个问题 [Boo11b]。该图是否显示系统如何响应输入或事件?哪些可视化可能有助于强调风险领域?如何使隐藏的系统设计模式对其他开发人员来说更加明显?多个观点能否展示重构系统特定部分的最佳方法?设计权衡能否以有意义的方式表示?如果软件架构的图形表示能够回答这些问题,那么它将对使用它的软件工程师有价值。

Several questions [Boo11b] must be asked and answered as a software engineer creates meaningful architectural diagrams. Does the diagram show how the system responds to inputs or events? What visualizations might there be to help emphasize areas of risk? How can hidden system design patterns be made more obvious to other developers? Can multiple viewpoints show the best way to refactor specific parts of the system? Can design trade-offs be represented in a meaningful way? If a diagrammatic representation of software architecture answers these questions, it will have value to software engineers that use it.

10.6.1 在上下文中表示系统

10.6.1 Representing the System in Context

UML 不包含在上下文中表示系统的特定图表。希望坚持使用 UML 并在上下文中表示系统的软件工程师可以结合用例、类、组件、活动、序列和协作图来实现。一些软件架构师可能会利用架构上下文图(ACD)来对软件与其边界外部的实体交互的方式进行建模。SafeHome安全功能的架构上下文图如图 10.7所示。第 197 页

UML does not contain specific diagrams that represent the system in context. Software engineers wishing to stick with UML and represent the system in context would do so with a combination of use case, class, component, activity, sequence, and collaboration diagrams. Some software architects may make use of an architectural context diagram (ACD) to model the manner in which software interacts with entities external to its boundaries. An architectural context diagram for the SafeHome security functions is shown in Figure 10.7.Page 197

10.7 SafeHome 安全功能的架构上下文

Figure 10.7 Architectural context diagram for the SafeHome security function

为了说明 ACD 的使用,请考虑图 10.7中所示的SafeHome产品的家庭安全功能。整个SafeHome产品控制器和基于互联网的系统都高于安全功能,并显示在该功能之上。监视功能是对等系统,并在产品的后续版本中使用(被使用)家庭安全功能。房主和控制面板是产生和消费分别由安全软件使用和产生的信息的参与者。最后,传感器由安全软件使用,并显示为从属于它(通过将它们绘制在目标系统下方)。

To illustrate the use of the ACD, consider the home security function of the SafeHome product shown in Figure 10.7. The overall SafeHome product controller and the Internet-based system are both superordinate to the security function and are shown above the function. The surveillance function is a peer system and uses (is used by) the home security function in later versions of the product. The homeowner and control panels are actors that produce and consume information that is, respectively, used and produced by the security software. Finally, sensors are used by the security software and are shown as subordinate to it (by drawing them below the target system).

作为架构设计的一部分,必须指定图 10.7中所示的每个接口的详细信息。在此阶段必须识别流入和流出目标系统的所有数据。

As part of the architectural design, the details of each interface shown in Figure 10.7 would have to be specified. All data that flow into and out of the target system must be identified at this stage.

10.6.2 定义原型

10.6.2 Defining Archetypes

原型是代表核心抽象的类或模式,对于目标系统体系结构设计至关重要。一般来说,即使设计相对复杂的系统,也需要相对较小的原型集。目标系统架构由这些原型组成,它们代表架构的稳定元素,但可以根据系统的行为以多种不同的方式实例化。

An archetype is a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system. In general, a relatively small set of archetypes is required to design even relatively complex systems. The target system architecture is composed of these archetypes, which represent stable elements of the architecture but may be instantiated many different ways based on the behavior of the system.

在许多情况下,可以通过检查定义为需求模型一部分的分析类来派生原型。继续讨论SafeHome家庭安全功能,您可以定义以下原型:

In many cases, archetypes can be derived by examining the analysis classes defined as part of the requirements model. Continuing the discussion of the SafeHome home security function, you might define the following archetypes:

  • 节点。表示家庭安全功能的输入和输出元素的紧密集合。例如,一个节点可能由 (1) 各种传感器和 (2) 各种警报(输出)指示器组成。

  • Node. Represents a cohesive collection of input and output elements of the home security function. For example, a node might be composed of (1) various sensors and (2) a variety of alarm (output) indicators.

  • 探测器。包含将信息输入目标系统的所有传感设备的抽象。

  • Detector. An abstraction that encompasses all sensing equipment that feeds information into the target system.

  • 第 198 页指标。表示用于指示警报条件正在发生的所有机制(例如警报器、闪光灯、铃声)的抽象。

  • Page 198Indicator. An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights, bell) for indicating that an alarm condition is occurring.

  • 控制器。描述允许节点布防或撤防的机制的抽象。如果控制器驻留在网络上,它们就能够相互通信。

  • Controller. An abstraction that depicts the mechanism that allows the arming or disarming of a node. If controllers reside on a network, they have the ability to communicate with one another.

每个原型都使用 UML 表示法进行描述,如图10.8所示。回想一下,原型构成了架构的基础,但它是抽象的,必须随着架构设计的进行进一步细化。例如,探测器可能会被细化为传感器的类层次结构。

Each of these archetypes is depicted using UML notation, as shown in Figure 10.8. Recall that the archetypes form the basis for the architecture but are abstractions that must be further refined as architectural design proceeds. For example, Detector might be refined into a class hierarchy of sensors.

图10.8 SafeHome 安全功能原型 UML 关系

Figure 10.8 UML relationships for SafeHome security function archetype

资料来源:改编自 Bosch、Jan 的《软件架构的设计与使用》。培生教育,2000。

Source: Adapted from Bosch, Jan, Design & Use of Software Architectures. Pearson Education, 2000.

10.6.3 将架构细化为组件

10.6.3 Refining the Architecture into Components

随着软件架构被细化为组件,系统的结构开始显现。但这些组件是如何选择的呢?要回答这个问题,您需要从作为需求模型一部分描述的类开始。6这些分析类代表应用程序(业务)域内必须在软件架构内解决的实体。因此,应用程序领域是组件的派生和细化的来源之一。另一个来源是基础设施领域。该体系结构必须容纳许多支持应用程序组件但与应用程序域没有业务连接的基础设施组件。例如,内存管理组件、通信组件、数据库组件和任务管理组件通常集成到软件架构中。

As the software architecture is refined into components, the structure of the system begins to emerge. But how are these components chosen? To answer this question, you begin with the classes that were described as part of the requirements model.6 These analysis classes represent entities within the application (business) domain that must be addressed within the software architecture. Hence, the application domain is one source for the derivation and refinement of components. Another source is the infrastructure domain. The architecture must accommodate many infrastructure components that enable application components but have no business connection to the application domain. For example, memory management components, communication components, database components, and task management components are often integrated into the software architecture.

第 199 页架构上下文图(第 10.6.1 节)中描述的接口意味着一个或多个处理流经接口的数据的专用组件。在某些情况下(例如,图形用户界面),必须设计具有许多组件的完整子系统架构。

Page 199The interfaces depicted in the architecture context diagram (Section 10.6.1) imply one or more specialized components that process the data that flows across the interface. In some cases (e.g., a graphical user interface), a complete subsystem architecture with many components must be designed.

继续SafeHome家庭安全功能示例,您可以定义一组解决以下功能的顶级组件:

Continuing the SafeHome home security function example, you might define the set of top-level components that addresses the following functionality:

  • 外部沟通管理。协调安全功能与外部实体(例如其他基于互联网的系统和外部警报通知)的通信。

  • External communication management. Coordinates communication of the security function with external entities such as other Internet-based systems and external alarm notification.

  • 控制面板处理。管理所有控制面板功能。

  • Control panel processing. Manages all control panel functionality.

  • 探测器管理。协调对连接到系统的所有探测器的访问。

  • Detector management. Coordinates access to all detectors attached to the system.

  • 报警处理。验证所有警报条件并采取行动。

  • Alarm processing. Verifies and acts on all alarm conditions.

这些顶层组件中的每一个都必须经过迭代地精心设计,然后定位在整个SafeHome架构中。将为每个定义设计类(具有适当的属性和操作)。然而,值得注意的是,所有属性和操作的设计细节直到组件级设计(第11章)才会被指定。

Each of these top-level components would have to be elaborated iteratively and then positioned within the overall SafeHome architecture. Design classes (with appropriate attributes and operations) would be defined for each. It is important to note, however, that the design details of all attributes and operations would not be specified until component-level design (Chapter 11).

整体架构结构(表示为 UML 组件图)如图 10.9所示。当事务从处理SafeHome GUI 和互联网接口的组件移入时,外部通信管理会获取事务。该信息由SafeHome执行组件管理,该执行组件选择适当的产品功能(在本例中为安全性)。控制面板处理组件与房主交互以布防和撤防安全功能。检测器管理组件轮询传感器以检测警报条件,并且警报处理组件在检测到警报时产生输出。

The overall architectural structure (represented as a UML component diagram) is illustrated in Figure 10.9. Transactions are acquired by external communication management as they move in from components that process the SafeHome GUI and the Internet interface. This information is managed by a SafeHome executive component that selects the appropriate product function (in this case security). The control panel processing component interacts with the homeowner to arm and disarm the security function. The detector management component polls sensors to detect an alarm condition, and the alarm processing component produces output when an alarm is detected.

图10.9 SafeHome 顶层组件整体架构结构

Figure 10.9 Overall architectural structure for SafeHome with top-level components

第200页

Page 200

10.6.4 描述系统的实例化

10.6.4 Describing Instantiations of the System

目前已经建模出来的建筑设计水平还是比较高的。系统的上下文已经被表示,指示问题域内的重要抽象的原型已经被定义,系统的整体结构是显而易见的,并且主要的软件组件已经被识别。然而,进一步的细化(回想一下,所有的设计都是迭代的)仍然是必要的。

The architectural design that has been modeled to this point is still relatively high level. The context of the system has been represented, archetypes that indicate the important abstractions within the problem domain have been defined, the overall structure of the system is apparent, and the major software components have been identified. However, further refinement (recall that all design is iterative) is still necessary.

为了实现这一点,开发了该架构的实际实例。我们的意思是,该架构应用于特定问题,目的是证明结构和组件是合适的。

To accomplish this, an actual instantiation of the architecture is developed. By this we mean that the architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.

图 10.10说明了安全系统的SafeHome架构的实例。图 10.9中所示的组件经过详细阐述以显示更多细节。例如,检测器管理组件与调度器基础设施组件交互,调度器基础设施组件实现对安全系统使用的每个传感器对象的轮询。对图 10.10中所示的每个组件进行类似的阐述。

Figure 10.10 illustrates an instantiation of the SafeHome architecture for the security system. Components shown in Figure 10.9 are elaborated to show additional detail. For example, the detector management component interacts with a scheduler infrastructure component that implements polling of each sensor object used by the security system. Similar elaboration is performed for each of the components represented in Figure 10.10.

图10.10带有组件细化 安全功能的实例

Figure 10.10 An instantiation of the security function with component elaboration

第201页

Page 201

10.7 评估替代架构设计

10.7 Assessing Alternative Architectural Designs

在他们关于软件架构评估的书中,Clements 和他的同事 [Cle03] 指出,“坦率地说,架构是一个赌注,是对系统成功的赌注。”

In their book on the evaluation of software architectures, Clements and his colleagues [Cle03] state, “To put it bluntly, an architecture is a bet, a wager on the success of a system.”

对于软件架构师和致力于构建系统的软件工程师来说,最大的问题很简单:架构上的赌注会得到回报吗?

The big question for a software architect and the software engineers who will work to build a system is simple: Will the architectural bet pay off?

为了帮助回答这个问题,架构设计应该产生许多架构替代方案,对每个替代方案进行评估以确定哪个最适合要解决的问题。

To help answer this question, architectural design should result in a number of architectural alternatives that are each assessed to determine which is the most appropriate for the problem to be solved.

软件工程研究所 (SEI) 开发了一种架构权衡分析方法(ATAM) [Kaz98],为软件架构建立了迭代评估流程。接下来的设计分析活动是迭代执行的:

The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM) [Kaz98] that establishes an iterative evaluation process for software architectures. The design analysis activities that follow are performed iteratively:

  1. 收集场景。开发了一组用例(第 7 章和第 8 章)来从用户的角度表示系统。

  2. Collect scenarios. A set of use cases (Chapters 7 and 8) is developed to represent the system from the user’s point of view.

  3. 得出需求、约束和环境描述。该信息是需求工程的一部分,用于确保所有涉众关注的问题均已得到解决。

  4. Elicit requirements, constraints, and environment description. This information is required as part of requirements engineering and is used to be certain that all stakeholder concerns have been addressed.

  5. 描述为解决场景和需求而选择的架构风格和模式。应使用以下架构视图之一来描述架构风格:

    • 模块视图,用于分析组件的工作分配以及信息隐藏的实现程度。

    • 用于分析系统性能的过程视图。

    • 数据流视图,用于分析架构满足功能需求的程度。

  6. Describe the architectural styles and patterns that have been chosen to address the scenarios and requirements. The architectural style(s) should be described using one of the following architectural views:

    • Module view for analysis of work assignments with components and the degree to which information hiding has been achieved.

    • Process view for analysis of system performance.

    • Data flow view for analysis of the degree to which the architecture meets functional requirements.

  7. 通过单独考虑每个属性来评估质量属性。选择用于分析的质量属性的数量是可用于审查的时间以及质量属性与当前系统的相关程度的函数。架构设计评估的质量属性包括可靠性、性能、安全性、可维护性、灵活性、可测试性、可移植性、可重用性和互操作性。

  8. Evaluate quality attributes by considering each attribute in isolation. The number of quality attributes chosen for analysis is a function of the time available for review and the degree to which quality attributes are relevant to the system at hand. Quality attributes for architectural design assessment include reliability, performance, security, maintainability, flexibility, testability, portability, reusability, and interoperability.

  9. 确定质量属性对特定架构风格的各种架构属性的敏感性。这可以通过对架构进行小的更改并确定质量属性(例如性能)对更改的敏感程度来实现。受架构变化显着影响的任何属性都称为敏感点。

  10. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. This can be accomplished by making small changes in the architecture and determining how sensitive a quality attribute, say performance, is to the change. Any attributes that are significantly affected by variation in the architecture are termed sensitivity points.

  11. 使用步骤 5 中进行的敏感性分析来批评候选架构(在步骤 3 中开发)。SEI 按以下方式描述此方法 [Kaz98]:

    一旦确定了架构敏感点,寻找权衡点就是简单地识别多个属性对其敏感的架构元素。例如,客户端-服务器体系结构的性能可能对服务器数量高度敏感(在一定范围内,通过增加服务器数量来提高性能)。。。。那么,服务器的数量是该架构的一个权衡点。第202页

  12. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. The SEI describes this approach in the following manner [Kaz98]:

    Once the architectural sensitivity points have been determined, finding trade-off points is simply the identification of architectural elements to which multiple attributes are sensitive. For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases, within some range, by increasing the number of servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.Page 202

这六个步骤代表第一次 ATAM 迭代。基于步骤5和6的结果,可以消除一些架构替代方案,可以修改和更详细地表示剩余架构中的一个或多个,然后重新应用ATAM步骤。

These six steps represent the first ATAM iteration. Based on the results of steps 5 and 6, some architecture alternatives may be eliminated, one or more of the remaining architectures may be modified and represented in more detail, and then the ATAM steps are reapplied.

10.7.1 架构审查

10.7.1 Architectural Reviews

架构审查是一种专门的技术审查(第16章),它提供了一种评估软件架构满足系统质量要求(例如,可扩展性或性能)的能力并识别任何潜在风险的方法。架构审查有可能通过及早发现设计问题来降低项目成本。第203页

Architectural reviews are a type of specialized technical review (Chapter 16) that provide a means of assessing the ability of a software architecture to meet the system’s quality requirements (e.g., scalability or performance) and to identify any potential risks. Architectural reviews have the potential to reduce project costs by detecting design problems early.Page 203

与涉及所有利益相关者代表的需求评审不同,架构评审通常仅涉及由独立专家补充的软件工程团队成员。然而,基于软件的系统是由具有各种不同需求和观点的人构建的。在创建架构时,架构师通常会关注系统非功能性需求的长期影响。高级管理人员在业务目标的背景下评估架构。项目经理常常受到交付日期和预算的短期考虑的驱动。软件工程师通常专注于自己的技术兴趣和功能交付。这些(和其他)支持者中的每一个都必须同意所选择的软件架构比任何其他替代方案具有明显的优势。因此,明智的软件架构师应该在软件团队成员(和其他利益相关者)之间建立共识,以实现最终软件产品的架构愿景[Wri11]。

Unlike requirements reviews that involve representatives of all stakeholders, architecture reviews often involve only software engineering team members supplemented by independent experts. However, software-based systems are built by people with a variety of different needs and points of view. Architects often focus on the long-term impact of the system’s nonfunctional requirements as the architecture is created. Senior managers assess the architecture within the context of business goals and objectives. Project managers are often driven by short-term considerations of delivery dates and budget. Software engineers are often focused on their own technology interests and feature delivery. Each of these (and other) constituencies must agree that the software architecture chosen has distinct advantages over any other alternatives. Therefore, a wise software architect should build consensus among members of the software team (and other stakeholders) to achieve the architectural vision for the final software product [Wri11].

行业中最常见的架构审查技术是:基于经验的推理、原型评估、场景审查(第 8 章)和检查表的使用。许多架构审查发生在项目生命周期的早期;它们也应该发生在基于组件的设计中获取新组件或包之后(第 11 章)。软件工程师在进行架构审查时面临的最常见问题之一是架构工作产品缺失或不足,从而导致审查难以完成[Bab09]。

The most common architectural review techniques used in industry are: experience-based reasoning, prototype evaluation, scenario review (Chapter 8), and use of checklists. Many architectural reviews occur early in the project life cycle; they should also occur after new components or packages are acquired in component-based design (Chapter 11). One of the most commonly cited problems facing software engineers when conducting architectural reviews is missing or inadequate architectural work products, thereby making review difficult to complete [Bab09].

10.7.2 基于模式的架构审查

10.7.2 Pattern-Based Architecture Review

正式的技术评审(第 16 章)可以应用于软件架构,并提供管理系统质量属性、发现错误和避免不必要的返工的方法。然而,在构建周期短、期限紧迫、需求不稳定和/或团队规模较小的情况下,称为基于模式的架构审查 (PBAR) 的轻量级架构审查流程可能是最佳选择

Formal technical reviews (Chapter 16) can be applied to software architecture and provide a means for managing system quality attributes, uncovering errors, and avoiding unnecessary rework. However, in situations in which short build cycles, tight deadlines, volatile requirements, and/or small teams are the norm, a lightweight architectural review process known as pattern-based architecture review (PBAR) might be the best option.

PBAR 是一种基于架构模式7的评估方法,它利用模式与质量属性的关系。PBAR 是一次面对面的审核会议,所有开发人员和其他感兴趣的利益相关者都参与其中。一位在架构、架构模式、质量属性和应用程序领域具有专业知识的外部评审员也出席了会议。系统架构师是主要演示者。

PBAR is an evaluation method based on architectural patterns7 that leverages the patterns’ relationships to quality attributes. A PBAR is a face-to-face audit meeting involving all developers and other interested stakeholders. An external reviewer with expertise in architecture, architecture patterns, quality attributes, and the application domain is also in attendance. The system architect is the primary presenter.

PBAR应当在第一个工作原型或行走骨架8完成之后安排。PBAR 包含以下迭代步骤 [Har11]:

A PBAR should be scheduled after the first working prototype or walking skeleton8 is completed. The PBAR encompasses the following iterative steps [Har11]:

  1. 通过浏览相关用例来识别和讨论对系统最重要的质量属性(第 8 章)。

  2. Identify and discuss the quality attributes most important to the system by walking through the relevant use cases (Chapter 8).

  3. 讨论与其需求相关的系统架构图。

  4. Discuss a diagram of the system’s architecture in relation to its requirements.

  5. 帮助审阅者识别所使用的架构模式并将系统的结构与模式的结构相匹配。第204页

  6. Help the reviewer identify the architecture patterns used and match the system’s structure to the patterns’ structure.Page 204

  7. 使用现有文档和过去的用例,检查架构和质量属性,以确定每个模式对系统质量属性的影响。

  8. Using existing documentation and past use cases, examine the architecture and quality attributes to determine each pattern’s effect on the system’s quality attributes.

  9. 识别并讨论设计中使用的架构模式引发的所有质量问题。

  10. Identify and discuss all quality issues raised by architecture patterns used in the design.

  11. 对会议期间发现的问题进行简短总结,并对行走框架进行适当的修改。

  12. Develop a short summary of the issues uncovered during the meeting, and make appropriate revisions to the walking skeleton.

PBAR 非常适合小型敏捷团队,并且需要相对少量的额外项目时间和精力。PBAR 的准备和审核时间较短,可以适应不断变化的需求和较短的构建周期,同时有助于提高团队对系统架构的理解。

PBARs are well suited to small, agile teams and require a relatively small amount of extra project time and effort. With its short preparation and review time, PBAR can accommodate changing requirements and short build cycles and, at the same time, help improve the team’s understanding of the system architecture.

10.7.3 架构一致性检查

10.7.3 Architecture Conformance Checking

随着软件流程从设计进入构建,软件工程师必须努力确保已实施和不断发展的系统符合其计划的架构。许多因素(例如,冲突的需求、技术困难、截止日期压力)都会导致与定义的架构的偏差。如果不定期检查架构的一致性,不受控制的偏差可能会导致架构侵蚀并影响系统的质量[Pas10]。

As the software process moves through design and into construction, software engineers must work to ensure that an implemented and evolving system conforms to its planned architecture. Many things (e.g., conflicting requirements, technical difficulties, deadline pressures) cause deviations from a defined architecture. If architecture is not checked for conformance periodically, uncontrolled deviations can cause architecture erosion and affect the quality of the system [Pas10].

静态架构一致性分析(SACA)评估已实现的软件系统是否与其架构模型一致。用于对系统架构进行建模的形式主义(例如,UML)呈现了系统组件的静态组织以及组件如何交互。项目经理通常使用架构模型来计划和分配工作任务,以及评估实施进度。

Static architecture-conformance analysis (SACA) assesses whether an implemented software system is consistent with its architectural model. The formalism (e.g., UML) used to model the system architecture presents the static organization of system components and how the components interact. Often the architectural model is used by a project manager to plan and allocate work tasks, as well as to assess implementation progress.

10.8 总结

10.8 Summary

软件架构提供了要构建的系统的整体视图。它描述了软件组件的结构和组织、它们的属性以及它们之间的连接。软件组件包括程序模块和程序操作的各种数据表示。因此,数据设计是软件架构推导过程中不可或缺的一部分。架构突出了早期的设计决策,并提供了一种考虑替代系统结构的好处的机制。

Software architecture provides a holistic view of the system to be built. It depicts the structure and organization of software components, their properties, and the connections between them. Software components include program modules and the various data representations that are manipulated by the program. Therefore, data design is an integral part of the derivation of the software architecture. Architecture highlights early design decisions and provides a mechanism for considering the benefits of alternative system structures.

通过应用混合架构设计框架,架构设计可以与敏捷方法共存,该框架利用源自流行敏捷方法的现有技术。一旦开发了架构,就可以对其进行评估,以确保符合业务目标、软件需求和质量属性。

Architectural design can coexist with agile methods by applying a hybrid architectural design framework that makes use of existing techniques derived from popular agile methods. Once an architecture is developed, it can be assessed to ensure conformance with business goals, software requirements, and quality attributes.

软件工程师可以使用几种不同的架构风格和模式,并且可以将其应用于给定的架构类型。每种风格描述了一个系统类别,其中包含一组执行系统所需功能的组件;一组连接器,可实现组件之间的通信、协调和合作;定义如何集成组件以形成系统的约束;语义模型使设计人员能够理解系统的整体属性。第205页

Several different architectural styles and patterns are available to the software engineer and may be applied within a given architectural genre. Each style describes a system category that encompasses a set of components that perform a function required by a system; a set of connectors that enable communication, coordination, and cooperation among components; constraints that define how components can be integrated to form the system; and semantic models that enable a designer to understand the overall properties of a system.Page 205

一般来说,架构设计是通过四个不同的步骤来完成的。首先,系统必须在上下文中表示。也就是说,设计者应该定义软件与之交互的外部实体以及交互的性质。一旦指定了上下文,设计者就应该确定一组顶级抽象,称为原型,它们代表系统行为或功能的关键元素。定义抽象之后,设计开始向实现领域靠拢。组件在支持它们的架构的上下文中被识别和表示。最后,开发架构的具体实例以在现实环境中“证明”设计。

In a general sense, architectural design is accomplished using four distinct steps. First, the system must be represented in context. That is, the designer should define the external entities that the software interacts with and the nature of the interaction. Once context has been specified, the designer should identify a set of top-level abstractions, called archetypes, that represent pivotal elements of the system’s behavior or function. After abstractions have been defined, the design begins to move closer to the implementation domain. Components are identified and represented within the context of an architecture that supports them. Finally, specific instantiations of the architecture are developed to “prove” the design in a real-world context.

问题与思考点

Problems and Points to Ponder

10.1. 使用房屋或建筑物的架构作为比喻,与软件架构进行比较。经典架构和软件架构的学科有何相似之处?它们有何不同?

10.1. Using the architecture of a house or building as a metaphor, draw comparisons with software architecture. How are the disciplines of classical architecture and the software architecture similar? How do they differ?

10.2. 为第 10.3.1 节中提到的每种架构风格提供两个或三个应用程序示例。

10.2. Present two or three examples of applications for each of the architectural styles noted in Section 10.3.1.

10.3. 第 10.3.1 节中提到的一些架构风格本质上是分层的,而另一些则不是。列出每种类型。非层次化的架构风格如何实现?

10.3. Some of the architectural styles noted in Section 10.3.1 are hierarchical in nature, and others are not. Make a list of each type. How would the architectural styles that are not hierarchical be implemented?

10.4. 在讨论软件架构时经常会遇到术语架构风格、架构模式框架(本书中未讨论)。做一些研究,并描述每个术语与其对应术语的不同之处。

10.4. The terms architectural style, architectural pattern, and framework (not discussed in this book) are often encountered in discussions of software architecture. Do some research, and describe how each of these terms differs from its counterparts.

10.5。选择您熟悉的应用程序。回答第 10.3.3 节中针对控制和数据提出的每个问题。

10.5. Select an application with which you are familiar. Answer each of the questions posed for control and data in Section 10.3.3.

10.6。研究 ATAM(使用 [Kaz98]),并详细讨论第 10.7.1 节中提出的六个步骤。

10.6. Research the ATAM (using [Kaz98]), and present a detailed discussion of the six steps presented in Section 10.7.1.

10.7。如果您还没有这样做,请完成问题 8.3。使用本章中描述的设计方法来开发坑洞跟踪和修复系统(PHTRS)的软件架构。

10.7. If you haven’t done so, complete Problem 8.3. Use the design approach described in this chapter to develop a software architecture for the pothole tracking and repair system (PHTRS).

10.8。使用第 10.1.4 节中的架构决策模板来记录问题 10.7中开发的 PHTRS 架构的架构决策之一。

10.8. Use the architectural decision template from Section 10.1.4 to document one of the architectural decisions for PHTRS architecture developed in Problem 10.7.

10.9。选择您熟悉的移动应用程序,并使用第10.4 节中的架构考虑因素(经济性、可见性、间距、对称性、出现)对其进行评估。

10.9. Select a mobile application you are familiar with, and assess it using the architecture considerations (economy, visibility, spacing, symmetry, emergence) from Section 10.4.

10.10。列出您为问题 10.7创建的 PHTRS 架构的优点和缺点。

10.10. List the strengths and weakness of the PHTRS architecture you created for Problem 10.7.

1 主导设计描述了一种创新的软件架构或流程,经过一段时间的市场成功适应和使用后,该架构或流程成为行业标准。

1 Dominant design describes an innovative software architecture or process that becomes an industry standard after a period of successful adaptation and use in the marketplace.

2关于架构敏捷性的精彩讨论可以在 [Bro10a] 中找到。

2 An excellent discussion of architectural agility can be found in [Bro10a].

3有关架构风格和模式的详细讨论,请参阅 [Roz11]、[Tay09]、[Bus07]、[Gor06] 或 [Bas12]。

3 See [Roz11], [Tay09], [Bus07], [Gor06], or [Bas12] for a detailed discussion of architectural styles and patterns.

4第 13 章更详细地讨论了 MVC 架构。

4 The MVC architecture is considered in more detail in Chapter 13.

5 SOAD 类似于第 14 章中讨论的架构模式的使用。

5 SOAD is analogous to the use of architecture patterns discussed in Chapter 14.

6如果选择传统的(非面向对象的)方法,组件可以从子程序调用层次中派生(见图 10.3)。

6 If a conventional (non-object-oriented) approach is chosen, components may be derived from the subprogram calling hierarchy (see Figure 10.3).

7架构模式是针对具有一组特定条件或约束的架构设计问题的通用解决方案。第 14 章详细讨论了模式。

7 An architectural pattern is a generalized solution to an architectural design problem with a specific set of conditions or constraints. Patterns are discussed in detail in Chapter 14.

8行走骨架包含一个基线架构,该架构支持业务案例中具有最高优先级的功能需求和最具挑战性的质量属性。

8 A walking skeleton contains a baseline architecture that supports the functional requirements with the highest priorities in the business case and the most challenging quality attributes.

第206页

Page 206

章节

chapter

11组件级设计

11 Component-Level Design

组件级设计发生在架构设计的第一次迭代完成之后。到此阶段,软件的整体数据和程序结构已经建立。目的是将设计模型转化为操作软件。但现有设计模型的抽象层次较高,而运行程序的抽象层次较低。翻译可能具有挑战性,可能会引入微妙的错误,而这些错误在软件过程的后期阶段很难发现和纠正。组件级设计弥合了架构设计和编码之间的差距。

Component-level design occurs after the first iteration of architectural design has been completed. At this stage, the overall data and program structure of the software has been established. The intent is to translate the design model into operational software. But the level of abstraction of the existing design model is relatively high, and the abstraction level of the operational program is low. The translation can be challenging, opening the door to the introduction of subtle errors that are difficult to find and correct in later stages of the software process. Component-level design bridges the gap between architectural design and coding.

组件级设计将减少编码过程中引入的错误数量。当您将设计模型转换为源代码时,您应该遵循一组设计原则,这些原则不仅执行翻译,而且不会“从一开始就引入错误”。

Component-level design will reduce the number of errors introduced during coding. As you translate the design model into source code, you should follow a set of design principles that not only perform the translation but also do not “introduce bugs to start with.”

第207页

Page 207

11.1 什么是组件?

11.1 What Is a Component?

组件是计算机软件的模块化构建块。更正式地说,OMG 统一建模语言规范[OMG03a] 将组件定义为“封装实现并公开一组接口的系统的模块化、可部署和可替换的部分”。

A component is a modular building block for computer software. More formally, the OMG Unified Modeling Language Specification [OMG03a] defines a component as “a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”

正如我们在第 10 章中讨论的,组件填充软件架构并在实现要构建的系统的目标和要求方面发挥作用。由于组件驻留在软件架构内,因此它们必须与其他组件以及存在于软件边界之外的实体(例如其他系统、设备、人员)进行通信和协作。

As we discussed in Chapter 10, components populate the software architecture and play a role in achieving the objectives and requirements of the system to be built. Because components reside within the software architecture, they must communicate and collaborate with other components and with entities (e.g., other systems, devices, people) that exist outside the boundaries of the software.

术语“组件”的真正含义会根据使用它的软件工程师的观点而有所不同。在接下来的部分中,我们将研究什么是组件以及如何在设计建模过程中使用它的三个重要观点。

The true meaning of the term component will differ depending on the point of view of the software engineer who uses it. In the sections that follow, we examine three important views of what a component is and how it is used as design modeling proceeds.

11.1.1 面向对象的视图

11.1.1 An Object-Oriented View

在面向对象的软件工程环境中,组件包含一组协作类。1组件中的每个类都经过充分阐述,包括与其实现相关的所有属性和操作。作为设计细化的一部分,还必须定义使类能够与其他设计类进行通信和协作的所有接口。为了实现这一点,您从分析模型和详细分析类(针对与问题域相关的组件)和基础结构类(针对为问题域提供支持服务的组件)开始。

In the context of object-oriented software engineering, a component contains a set of collaborating classes.1 Each class within a component has been fully elaborated to include all attributes and operations that are relevant to its implementation. As part of the design elaboration, all interfaces that enable the classes to communicate and collaborate with other design classes must also be defined. To accomplish this, you begin with the analysis model and elaborate analysis classes (for components that relate to the problem domain) and infrastructure classes (for components that provide support services for the problem domain).

回想一下,分析建模和设计建模都是迭代操作。阐述原始分析类可能需要额外的分析步骤,然后进行设计建模步骤以表示阐述的设计类(组件的细节)。为了说明这一设计细化过程,请考虑为一家复杂的印刷店构建的软件。该软件的总体目的是在前台收集客户的要求,计算打印作业的成本,然后将作业传递到自动化生产设施。在需求工程过程中,派生了一个名为PrintJob的分析类。

Recall that analysis modeling and design modeling are both iterative actions. Elaborating the original analysis class may require additional analysis steps, which are then followed with design modeling steps to represent the elaborated design class (the details of the component). To illustrate this process of design elaboration, consider software to be built for a sophisticated print shop. The overall intent of the software is to collect the customer’s requirements at the front counter, cost a print job, and then pass the job on to an automated production facility. During requirements engineering, an analysis class called PrintJob was derived.

分析期间定义的属性和操作标注在图 11.1的顶部。在架构设计过程中,PrintJob被定义为软件架构中的一个组件,并使用图中右中所示的简写 UML 符号2来表示。请注意,PrintJob有两个接口:computeJob(提供作业成本计算功能)和initiateJob(将作业传递到生产设施)。它们使用组件框左侧显示的“棒棒糖”符号来表示。第208页

The attributes and operations defined during analysis are noted at the top of Figure 11.1. During architectural design, PrintJob is defined as a component within the software architecture and is represented using the shorthand UML notation2 shown in the middle right of the figure. Note that PrintJob has two interfaces, computeJob, which provides job costing capability, and initiateJob, which passes the job along to the production facility. These are represented using the “lollipop” symbols shown to the left of the component box.Page 208

组件级设计从此时开始。必须详细阐述组件PrintJob的详细信息,以提供足够的信息来指导实现。原始分析类经过精心设计,充实了将该类实现为组件PrintJob 所需的所有属性和操作。参考图11.1的右下部分,详细的设计类PrintJob包含更详细的属性信息以及实现该组件所需的操作的扩展描述。接口computeJobinitiateJob意味着与其他组件(此处未显示)的通信和协作。例如,操作computePageCost() ( computeJob接口的一部分)可能与包含作业定价信息的PricingTable组件协作。checkPriority ()操作( initiateJob接口的一部分)可以与JobQueue组件协作来确定当前等待生产的作业的类型和优先级。第209页

Component-level design begins at this point. The details of the component PrintJob must be elaborated to provide sufficient information to guide implementation. The original analysis class is elaborated to flesh out all attributes and operations required to implement the class as the component PrintJob. Referring to the lower right portion of Figure 11.1, the elaborated design class PrintJob contains more detailed attribute information as well as an expanded description of operations required to implement the component. The interfaces computeJob and initiateJob imply communication and collaboration with other components (not shown here). For example, the operation computePageCost() (part of the computeJob interface) might collaborate with a PricingTable component that contains job pricing information. The checkPriority() operation (part of the initiateJob interface) might collaborate with a JobQueue component to determine the types and priorities of jobs currently awaiting production.Page 209

图11.1 设计组件的详细阐述

Figure 11.1 Elaboration of a design component

此细化活动适用于定义为架构设计一部分的每个组件。一旦完成,将对每个属性、操作和接口进行进一步的细化。必须指定适合每个属性的数据结构。此外,还设计了实现与每个操作相关的处理逻辑所需的算法细节。这一程序设计活动将在本章后面讨论。最后,设计了实现该接口所需的机制。对于面向对象的软件,这可能涵盖实现系统内对象之间的通信所需的所有消息传递的描述。

This elaboration activity is applied to every component defined as part of the architectural design. Once it is completed, further elaboration is applied to each attribute, operation, and interface. The data structures appropriate for each attribute must be specified. In addition, the algorithmic detail required to implement the processing logic associated with each operation is designed. This procedural design activity is discussed later in this chapter. Finally, the mechanisms required to implement the interface are designed. For object-oriented software, this may encompass the description of all messaging that is required to effect communication between objects within the system.

11.1.2 传统观点

11.1.2 The Traditional View

在传统软件工程的背景下,组件是程序的功能元素,它包含处理逻辑、实现处理逻辑所需的内部数据结构以及允许调用组件和传递数据的接口到它。传统组件(也称为模块)驻留在软件体系结构中,并充当三个重要角色之一:(1)协调所有其他问题域组件的调用的控制组件,(2)实现完整解决方案的问题域组件。或客户所需的部分功能,或 (3)负责支持问题域中所需处理的功能的基础设施组件。

In the context of traditional software engineering, a component is a functional element of a program that incorporates processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it. A traditional component, also called a module, resides within the software architecture and serves one of three important roles: (1) a control component that coordinates the invocation of all other problem domain components, (2) a problem domain component that implements a complete or partial function that is required by the customer, or (3) an infrastructure component that is responsible for functions that support the processing required in the problem domain.

与面向对象的组件一样,传统的软件组件也是从分析模型派生出来的。然而,在这种情况下,分析模型的组件细化元素充当推导的基础。代表组件层次结构的每个组件都被映射(第 9 章),并在组件详细说明时应用。

Like object-oriented components, traditional software components are derived from the analysis model. In this case, however, the component elaboration element of the analysis model serves as the basis for the derivation. Each component representing the component hierarchy is mapped (Chapter 9) are applied as components are elaborated.

为了说明传统组件的设计细化过程,再次考虑为前面提到的印刷店构建的软件。分层架构被推导并如图 11.2所示。每个框代表一个软件组件。请注意,阴影框在功能上与第 11.1.1 节中讨论的PrintJob类定义的操作等效。然而,在这种情况下,每个操作都表示为调用的单独模块,如图所示。其他模块用于控制处理,因此是控制组件。第210页

To illustrate this process of design elaboration for traditional components, again consider software to be built for the print shop noted earlier. A hierarchical architecture is derived and shown in Figure 11.2. Each box represents a software component. Note that the shaded boxes are equivalent in function to the operations defined for the PrintJob class discussed in Section 11.1.1. In this case, however, each operation is represented as a separate module that is invoked as shown in the figure. Other modules are used to control processing and are therefore control components.Page 210

11.2 传统系统结构

Figure 11.2 Structure chart for a traditional system

在组件级设计中,对图11.2中的各个模块进行了详细阐述。模块接口是明确定义的。也就是说,流过接口的每个数据或控制对象都被表示。定义了模块内部使用的数据结构。允许模块完成其预期功能的算法是使用第9章中讨论的逐步细化方法来设计的。模块的行为有时使用状态图来表示。

During component-level design, each module in Figure 11.2 is elaborated. The module interface is defined explicitly. That is, each data or control object that flows across the interface is represented. The data structures that are used internal to the module are defined. The algorithm that allows the module to accomplish its intended function is designed using the stepwise refinement approach discussed in Chapter 9. The behavior of the module is sometimes represented using a state diagram.

为了说明此过程,请考虑模块ComputePageCost。该模块的目的是根据客户提供的规格计算每页的打印成本。执行此功能所需的数据有:文档中的页数、要生成的文档总数、单面或双面打印、颜色要求和尺寸要求。这些数据通过模块的接口传递到ComputePageCost 。ComputePageCost使用这些数据来确定基于作业的大小和复杂性的页面成本,这是通过接口传递到模块的所有数据的函数。页面成本与作业的大小成反比,与作业的复杂性成正比。

To illustrate this process, consider the module ComputePageCost. The intent of this module is to compute the printing cost per page based on specifications provided by the customer. Data required to perform this function are: number of pages in the document, total number of documents to be produced, one- or two-side printing, color requirements, and size requirements. These data are passed to ComputePageCost via the module’s interface. ComputePageCost uses these data to determine a page cost that is based on the size and complexity of the job—a function of all data passed to the module via the interface. Page cost is inversely proportional to the size of the job and directly proportional to the complexity of the job.

随着每个软件组件的设计被详细阐述,重点转移到特定数据结构的设计和操作数据结构的过程设计。图 11.3表示使用修改后的 UML 符号的组件级设计。ComputePageCost模块通过调用模块getJobData(允许将所有相关数据传递给组件)和数据库接口accessCostsDB(使模块能够访问包含所有打印成本的数据库)来访问数据随着设计的继续,ComputePageCost模块被详细设计以提供算法细节和接口细节(图 11.3)。算法细节可以使用图中所示的伪代码文本或 UML 活动图来表示。这些接口被表示为输入和输出数据对象或项的集合。继续进行设计细化,直到提供足够的细节来指导组件的构造。但是,不要忘记必须容纳组件的体系结构或可能为许多组件提供服务的全局数据结构。第211页

As the design for each software component is elaborated, the focus shifts to the design of specific data structures and procedural design to manipulate the data structures. Figure 11.3 represents the component-level design using a modified UML notation. The ComputePageCost module accesses data by invoking the module getJobData, which allows all relevant data to be passed to the component, and a database interface, accessCostsDB, which enables the module to access a database that contains all printing costs. As design continues, the ComputePageCost module is elaborated to provide algorithm detail and interface detail (Figure 11.3). Algorithm detail can be represented using the pseudocode text shown in the figure or with a UML activity diagram. The interfaces are represented as a collection of input and output data objects or items. Design elaboration continues until sufficient detail is provided to guide construction of the component. However, don’t forget the architecture that must house the components or the global data structures that may serve many components.Page 211

图11.3 ComputePageCost 组件级设计

Figure 11.3 Component-level design for ComputePageCost

11.1.3 流程相关视图

11.1.3 A Process-Related View

11.1.111.1.2节中介绍的组件级设计的面向对象和传统视图假设组件是从头开始设计的。也就是说,您始终根据从需求模型派生的规范来创建新组件。当然,还有另一种方法。第212页

The object-oriented and traditional views of component-level design presented in Sections 11.1.1 and 11.1.2 assume that the component is being designed from scratch. That is, you always create a new component based on specifications derived from the requirements model. There is, of course, another approach.Page 212

在过去的四十年中,软件工程社区一直强调需要构建利用现有软件组件或设计模式的系统。为此,随着设计工作的进行,需要向您提供经过验证的设计或代码级组件的目录。随着软件架构的开发,您可以从目录中选择组件或设计模式,并使用它们来填充架构。由于这些组件在创建时考虑了可重用性,因此您可以获取其接口、它们执行的功能以及它们所需的通信和协作的完整描述。我们将在第 11.4.4 节中讨论基于组件的软件工程 (CBSE) 的优缺点。

Over the past four decades, the software engineering community has emphasized the need to build systems that make use of existing software components or design patterns. To do this, a catalog of proven design or code-level components needs to be made available to you as design work proceeds. As the software architecture is developed, you choose components or design patterns from the catalog and use them to populate the architecture. Because these components have been created with reusability in mind, a complete description of their interface, the function(s) they perform, and the communication and collaboration they require are all available to you. We will save a discussion on the pros and cons of component-based software engineering (CBSE) for Section 11.4.4.

11.2 设计基于类的组件

11.2 Designing Class-Based Components

正如我们已经指出的,组件级设计利用了作为需求模型的一部分(第 8 章)开发的信息,并表示为体系结构模型的一部分(第 10 章)。当选择面向对象的软件工程方法时,组件级设计侧重于问题域特定类的详细说明以及需求模型中包含的基础结构类的定义和细化。这些类使用的属性、操作和接口的详细描述是作为构建活动的前提所需的设计细节。

As we have already noted, component-level design draws on information developed as part of the requirements model (Chapter 8) and represented as part of the architectural model (Chapter 10). When an object-oriented software engineering approach is chosen, component-level design focuses on the elaboration of problem domain specific classes and the definition and refinement of infrastructure classes contained in the requirements model. The detailed description of the attributes, operations, and interfaces used by these classes is the design detail required as a precursor to the construction activity.

11.2.1 基本设计原则

11.2.1 Basic Design Principles

四个基本设计原则适用于组件级设计,并在应用面向对象软件工程时被广泛采用。应用这些原则的根本动机是创建更易于更改的设计,并在发生更改时减少副作用的传播。在开发每个软件组件时,您可以使用这些原则作为指南。

Four basic design principles are applicable to component-level design and have been widely adopted when object-oriented software engineering is applied. The underlying motivation for the application of these principles is to create designs that are more amenable to change and to reduce the propagation of side effects when changes do occur. You can use these principles as a guide as each software component is developed.

开闭原则(OCP)。 “模块[组件]应该对扩展开放,但对修改关闭” [Mar00]。这种说法看似矛盾,但它代表了良好的组件级设计最重要的特征之一。简而言之,您应该以允许扩展(在它所处理的功能域内)的方式指定组件,而不需要对组件本身进行内部(代码或逻辑级别)修改。为了实现这一点,您需要创建抽象,作为可能扩展的功能和设计类本身之间的缓冲区。

The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification” [Mar00]. This statement seems to be a contradiction, but it represents one of the most important characteristics of a good component-level design. Stated simply, you should specify the component in a way that allows it to be extended (within the functional domain that it addresses) without the need to make internal (code or logic-level) modifications to the component itself. To accomplish this, you create abstractions that serve as a buffer between the functionality that is likely to be extended and the design class itself.

例如,假设SafeHome安全功能使用Detector类,该类必须检查每种类型的安全传感器的状态。随着时间的推移,安全传感器的数量和类型可能会增加。如果内部处理逻辑被实现为一系列 if-then-else 结构,每个结构寻址不同的传感器类型,则添加新的传感器类型将需要额外的内部处理逻辑(还有另一个 if-then-else)。这违反了 OCP。

For example, assume that the SafeHome security function makes use of a Detector class that must check the status of each type of security sensor. It is likely that as time passes, the number and types of security sensors will grow. If internal processing logic is implemented as a sequence of if-then-else constructs, each addressing a different sensor type, the addition of a new sensor type will require additional internal processing logic (still another if-then-else). This is a violation of OCP.

图 11.4说明了为Detector类实现 OCP 的一种方法。传感器接口向检测组件呈现传感器的一致视图。如果添加新类型的传感器,则无需更改Detector类(组件)。OCP 被保留。第213页

One way to accomplish OCP for the Detector class is illustrated in Figure 11.4. The sensor interface presents a consistent view of sensors to the detector component. If a new type of sensor is added, no change is required for the Detector class (component). The OCP is preserved.Page 213

11.4遵循 OCP

Figure 11.4 Following the OCP

第214页里氏替换原则(LSP)。 “子类应该可以替代它们的基类” [Mar00]。这一设计原则最初由 Barbara Liskov [Lis88] 提出,建议如果将从基类派生的类传递给组件,则使用基类的组件应该继续正常运行。LSP 要求从基类派生的任何类都必须遵守基类和使用它的组件之间的任何隐含契约。在此讨论的上下文中,“契约”是在组件使用基类之前必须为真的前提条件,以及在组件使用基类之后应该为真的后置条件。创建派生类时,请确保它们符合前置条件和后置条件。

Page 214The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base classes” [Mar00]. This design principle, originally proposed by Barbara Liskov [Lis88], suggests that a component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead. LSP demands that any class derived from a base class must honor any implied contract between the base class and the components that use it. In the context of this discussion, a “contract” is a precondition that must be true before the component uses a base class and a postcondition that should be true after the component uses a base class. When you create derived classes, be sure they conform to the pre- and postconditions.

依赖倒置原则(DIP)。 “依赖于抽象。不要依赖结核” [Mar00]。正如我们在 OCP 的讨论中所看到的,抽象是可以扩展设计而不会造成太大复杂性的地方。组件越依赖其他具体组件(而不是接口等抽象),扩展就越困难。请记住,代码是最终的具体化。如果您放弃设计并修改代码,那么您就违反了 DIP。

The Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions” [Mar00]. As we have seen in the discussion of the OCP, abstractions are the place where a design can be extended without great complication. The more a component depends on other concrete components (rather than on abstractions such as an interface), the more difficult it will be to extend. Just remember that code is the ultimate concretion. If you dispense with design and hack out code, you’re violating DIP.

接口隔离原则 (ISP)。 “许多特定于客户端的接口比一个通用接口更好” [Mar00]。在许多情况下,多个客户端组件使用服务器类提供的操作。ISP 建议您应该创建一个专门的接口来为每个主要类别的客户提供服务。仅应在该客户端的接口中指定那些与单个客户端类别相关的操作。如果多个客户端需要相同的操作,则应在每个专用接口中指定。

The Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one general purpose interface” [Mar00]. There are many instances in which multiple client components use the operations provided by a server class. ISP suggests that you should create a specialized interface to serve each major category of clients. Only those operations that are relevant to an individual client category should be specified in the interface for that client. If multiple clients require the same operations, it should be specified in each of the specialized interfaces.

作为一个例子,考虑用于SafeHome安全和监视功能的FloorPlan类(第 10 章)。对于安全功能,FloorPlan仅在配置活动期间使用,并使用操作placeDevice()、showDevice()、groupDevice()removeDevice()从平面图中放置、显示、分组和删除传感器。SafeHome监控功能使用四种安全操作,但还需要特殊操作来管理摄像头:showFOV ()showDeviceID()。因此,ISP 建议来自两个SafeHome功能的客户端组件具有为其定义的专用接口。安全接口仅包含placeDevice()、showDevice()、groupDevice()removeDevice()操作。监视接口将包含placeDevice()、showDevice()、groupDevice()removeDevice() 操作,以及showFOV()showDeviceID()。

As an example, consider the FloorPlan class that is used for the SafeHome security and surveillance functions (Chapter 10). For the security functions, FloorPlan is used only during configuration activities and uses the operations placeDevice(), showDevice(), groupDevice(), and removeDevice() to place, show, group, and remove sensors from the floor plan. The SafeHome surveillance function uses the four operations noted for security, but also requires special operations to manage cameras: showFOV() and showDeviceID(). Hence, the ISP suggests that client components from the two SafeHome functions have specialized interfaces defined for them. The interface for security would encompass only the operations placeDevice(), showDevice(), groupDevice(), and removeDevice(). The interface for surveillance would incorporate the operations placeDevice(), showDevice(), groupDevice(), and removeDevice(), along with showFOV() and showDeviceID().

尽管组件级设计原则提供了有用的指导,但组件本身并不存在于真空中。在许多情况下,各个组件或类被组织成子系统或包。有理由问这种包装活动应该如何发生。随着设计的进行,组件到底应该如何组织?Martin [Mar00] 提出了适用于组件级设计的附加封装原则。这些原则如下。

Although component-level design principles provide useful guidance, components themselves do not exist in a vacuum. In many cases, individual components or classes are organized into subsystems or packages. It is reasonable to ask how this packaging activity should occur. Exactly how should components be organized as the design proceeds? Martin [Mar00] suggests additional packaging principles that are applicable to component-level design. These principles follow.

重用/发布等效原则 (REP)。 “再利用的颗粒就是释放的颗粒” [Mar00]。当类或组件被设计为可重用时,可重用实体的开发人员和使用它的人员之间就会建立隐含的契约。开发者承诺建立一个发布控制系统,支持和维护旧版本的实体,同时用户慢慢升级到最新版本。通常建议将可重用的类分组到可以随着新版本的发展而进行管理和控制的包中,而不是单独处理每个类。设计可重用的组件需要的不仅仅是良好的技术设计。它还需要有效的配置控制机制(第22章)。第215页

The Reuse/Release Equivalency Principle (REP). “The granule of reuse is the granule of release” [Mar00]. When classes or components are designed for reuse, an implicit contract is established between the developer of the reusable entity and the people who will use it. The developer commits to establish a release control system that supports and maintains older versions of the entity while the users slowly upgrade to the most current version. Rather than addressing each class individually, it is often advisable to group reusable classes into packages that can be managed and controlled as newer versions evolve. Designing components for reuse requires more than good technical design. It also requires effective configuration control mechanisms (Chapter 22).Page 215

共同封闭原则(CCP)。 “一起改变的类属于同一类” [Mar00]。类应该紧密地打包。也就是说,当类被打包为设计的一部分时,它们应该解决相同的功能或行为领域。当该区域的某些特征必须更改时,很可能只有包中的那些类需要修改。这导致更有效的变更控制和发布管理。

The Common Closure Principle (CCP). “Classes that change together belong together” [Mar00]. Classes should be packaged cohesively. That is, when classes are packaged as part of a design, they should address the same functional or behavioral area. When some characteristic of that area must change, it is likely that only those classes within the package will require modification. This leads to more effective change control and release management.

共同重用原则(CRP)。 “不能一起重用的类不应分组在一起” [Mar00]。当一个包中的一个或多个类发生变化时,该包的版本号也会发生变化。依赖于已更改的包的所有其他类或包现在必须更新到该包的最新版本,并进行测试以确保新版本能够正常运行。如果类没有紧密地分组,则可能会更改与包中其他类没有关系的类。这将导致不必要的集成和测试。因此,只有一起重用的类才应包含在包中。

The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be grouped together” [Mar00]. When one or more classes with a package changes, the release number of the package changes. All other classes or packages that rely on the package that has been changed must now update to the most recent release of the package and be tested to ensure that the new release operated without incident. If classes are not grouped cohesively, it is possible that a class with no relationship to other classes within a package is changed. This will precipitate unnecessary integration and testing. For this reason, only classes that are reused together should be included within a package.

11.2.2 组件级设计指南

11.2.2 Component-Level Design Guidelines

除了第 11.2.1 节中讨论的原则之外,在组件级设计过程中还可以应用一组实用的设计指南。这些指南适用于组件、它们的接口以及对最终设计有影响的依赖关系和继承特征。Ambler [Amb02b] 建议遵循以下准则:

In addition to the principles discussed in Section 11.2.1, a set of pragmatic design guidelines can be applied as component-level design proceeds. These guidelines apply to components, their interfaces, and the dependencies and inheritance characteristics that have an impact on the resultant design. Ambler [Amb02b] suggests the following guidelines:

成分。应该为被指定为体系结构模型的一部分的组件建立命名约定,然后作为组件级模型的一部分进行细化和阐述。架构组件名称应该从问题域中提取,并且对于查看架构模型的所有利益相关者都应该有意义。例如,类名FloorPlan对于每个阅读它的人来说都是有意义的,无论技术背景如何。另一方面,基础设施组件或详细的组件级类的命名应反映特定于实现的含义。如果要将链表作为FloorPlan实现的一部分进行管理,则操作manageList()是合适的,即使非技术人员可能会误解它。3

Components. Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model. Architectural component names should be drawn from the problem domain and should have meaning to all stakeholders who view the architectural model. For example, the class name FloorPlan is meaningful to everyone reading it regardless of technical background. On the other hand, infrastructure components or elaborated component-level classes should be named to reflect implementation-specific meaning. If a linked list is to be managed as part of the FloorPlan implementation, the operation manageList() is appropriate, even if a nontechnical person might misinterpret it.3

您可以选择使用构造型来帮助在详细设计级别识别组件的性质。例如,<<infrastruction>>可用于标识基础结构组件,<<database>>可用于标识为一个或多个设计类或整个系统提供服务的数据库,并且<<table>>可用于识别数据库中的表。第216页

You can choose to use stereotypes to help identify the nature of components at the detailed design level. For example, <<infrastructure>> might be used to identify an infrastructure component, <<database>> could be used to identify a database that services one or more design classes or the entire system, and <<table>> can be used to identify a table within a database.Page 216

接口。接口提供了有关通信和协作的重要信息(以及帮助我​​们实现 OPC)。然而,不受约束的接口表示往往会使组件图变得复杂。Ambler [Amb02c] 建议 (1) 当图表变得复杂时,应使用接口的棒棒糖表示来代替更正式的 UML 框和虚线箭头方法,(2) 为了保持一致性,接口应从左侧流动(3) 仅应显示与所考虑的组件相关的那些接口,即使其他接口可用。这些建议旨在简化 UML 组件图的可视化特性。

Interfaces. Interfaces provide important information about communication and collaboration (as well as helping us to achieve the OPC). However, unfettered representation of interfaces tends to complicate component diagrams. Ambler [Amb02c] recommends that (1) lollipop representation of an interface should be used in lieu of the more formal UML box and dashed arrow approach, when diagrams grow complex, (2) for consistency, interfaces should flow from the left-hand side of the component box, (3) only those interfaces that are relevant to the component under consideration should be shown, even if other interfaces are available. These recommendations are intended to simplify the visual nature of UML component diagrams.

依赖和继承。为了提高可读性,最好从左到右对依赖关系进行建模,并从底部(派生类)到顶部(基类)对继承进行建模。此外,组件的相互依赖关系应该通过接口来表示,而不是通过组件之间的依赖关系来表示。遵循 OCP 的理念,这将有助于使系统更具可维护性。

Dependencies and Inheritance. For improved readability, it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes). In addition, components’ interdependencies should be represented via interfaces, rather than by representation of a component-to-component dependency. Following the philosophy of the OCP, this will help to make the system more maintainable.

11.2.3 内聚力

11.2.3 Cohesion

第 9 章中,我们将内聚力描述为组件的“专心致志”。在面向对象系统的组件级设计的上下文中,内聚意味着组件或类仅封装彼此以及与类或组件本身密切相关的属性和操作。Lethbridge 和 Laganiére [Let04] 定义了几种不同类型的内聚力(按内聚力水平的顺序列出):4

In Chapter 9, we described cohesion as the “single-mindedness” of a component. Within the context of component-level design for object-oriented systems, cohesion implies that a component or class encapsulates only attributes and operations that are closely related to each other and to the class or component itself. Lethbridge and Laganiére [Let04] define several different types of cohesion (listed in order of the level of the cohesion):4

功能齐全。主要通过操作表现出来,当模块执行一次且仅一次计算然后返回结果时,就会出现这种级别的内聚性。

Functional. Exhibited primarily by operations, this level of cohesion occurs when a module performs one and only one computation and then returns a result.

层。通过包、组件和类来表现,当较高层访问较低层的服务,但较低层不访问较高层时,就会发生这种类型的内聚。例如,考虑SafeHome安全功能要求在检测到警报时拨打电话。可以定义一组分层包,如图11.5所示。阴影包包含基础设施组件。访问是从控制面板包向下进行的。

Layer. Exhibited by packages, components, and classes, this type of cohesion occurs when a higher layer accesses the services of a lower layer, but lower layers do not access higher layers. Consider, for example, the SafeHome security function requirement to make an outgoing phone call if an alarm is sensed. It might be possible to define a set of layered packages, as shown in Figure 11.5. The shaded packages contain infrastructure components. Access is from the control panel package downward.

图11.5 内聚力

Figure 11.5 Layer cohesion

沟通。访问相同数据的所有操作都在一个类中定义。一般来说,此类类仅关注相关数据、访问和存储数据。

Communicational. All operations that access the same data are defined within one class. In general, such classes focus solely on the data in question, accessing and storing it.

第217页表现出功能、层和通信内聚性的类和组件相对容易实现、测试和维护。只要有可能,您就应该努力达到这些水平的凝聚力。然而,值得注意的是,实用的设计和实现问题有时会迫使您选择较低级别的内聚性。

Page 217Classes and components that exhibit functional, layer, and communicational cohesion are relatively easy to implement, test, and maintain. You should strive to achieve these levels of cohesion whenever possible. It is important to note, however, that pragmatic design and implementation issues sometimes force you to opt for lower levels of cohesion.

11.2.4 耦合

11.2.4 Coupling

在之前对分析和设计的讨论中,我们注意到通信和协作是任何面向对象系统的基本要素。然而,这一重要(且必要)的特征也有其阴暗的一面。随着沟通和协作量的增加(即,随着类之间“联系”程度的增加),系统的复杂性也会增加。随着复杂性的增加,实施、测试和维护软件的难度也随之增加。

In earlier discussions of analysis and design, we noted that communication and collaboration are essential elements of any object-oriented system. There is, however, a darker side to this important (and necessary) characteristic. As the amount of communication and collaboration increases (i.e., as the degree of “connectedness” between classes increases), the complexity of the system also increases. And as complexity increases, the difficulty of implementing, testing, and maintaining software grows.

耦合是类之间相互连接程度的一种定性度量。随着类(和组件)变得更加相互依赖,耦合性也会增加。组件级设计的一个重要目标是保持尽可能低的耦合。

Coupling is a qualitative measure of the degree to which classes are connected to one another. As classes (and components) become more interdependent, coupling increases. An important objective in component-level design is to keep coupling as low as possible.

类耦合可以通过多种方式表现出来。Lethbridge 和 Laganiére [Let04] 定义了一系列耦合类别。例如,当一个组件“秘密修改另一组件内部的数据”时,就会发生内容耦合[Let04]。这违反了信息隐藏这一基本设计理念。当操作A()调用操作B()并将控制标志传递给B时,就会发生控制耦合。然后,控制标志“指导” B内的逻辑流。这种形式的耦合的问题在于,B中不相关的更改可能会导致需要改变A传递的控制标志的含义。如果忽略这一点,将会导致错误。当组件与基础设施组件(例如,操作系统功能、数据库功能、电信功能)通信或协作时,就会发生外部耦合。尽管这种类型的耦合是必要的,但它应该仅限于系统内的少量组件或类。第219页

Class coupling can manifest itself in a variety of ways. Lethbridge and Laganiére [Let04] define a spectrum of coupling categories. For example, content coupling occurs when one component “surreptitiously modifies data that is internal to another component” [Let04]. This violates information hiding—a basic design concept. Control coupling occurs when operation A() invokes operation B() and passes a control flag to B. The control flag then “directs” logical flow within B. The problem with this form of coupling is that an unrelated change in B can result in the necessity to change the meaning of the control flag that A passes. If this is overlooked, an error will result. External coupling occurs when a component communicates or collaborates with infrastructure components (e.g., operating system functions, database capability, telecommunication functions). Although this type of coupling is necessary, it should be limited to a small number of components or classes within a system.Page 219

软件必须进行内部和外部通信。因此,耦合是生活中的一个事实。然而,设计人员应尽可能减少耦合,并在无法避免时了解高耦合的后果。

Software must communicate internally and externally. Therefore, coupling is a fact of life. However, a designer should work to reduce coupling whenever possible and understand the ramifications of high coupling when it cannot be avoided.

11.3 进行组件级设计

11.3 Conducting Component-Level Design

在本章前面,我们注意到组件级设计本质上是精细的。您必须将需求和架构模型中的信息转换为设计表示,以提供足够的细节来指导构建(编码和测试)活动。以下步骤代表了组件级设计应用于面向对象系统时的典型任务集。

Earlier in this chapter we noted that component-level design is elaborative in nature. You must transform information from requirements and architectural models into a design representation that provides sufficient detail to guide the construction (coding and testing) activity. The following steps represent a typical task set for component-level design, when it is applied for an object-oriented system.

步骤 1. 识别与问题域相对应的所有设计类。使用需求和架构模型,每个分析类和架构组件都按照第 11.1.1 节中的描述进行详细说明。

Step 1. Identify all design classes that correspond to the problem domain. Using the requirements and architectural model, each analysis class and architectural component is elaborated as described in Section 11.1.1.

步骤 2. 识别与基础设施域相对应的所有设计类。这些类没有在需求模型中描述,并且通常在体系结构模型中缺失,但此时必须对它们进行描述。正如我们之前提到的,此类中的类和组件包括 GUI 组件(通常作为可重用组件)、操作系统组件以及对象和数据管理组件。第220页

Step 2. Identify all design classes that correspond to the infrastructure domain. These classes are not described in the requirements model and are often missing from the architecture model, but they must be described at this point. As we have noted earlier, classes and components in this category include GUI components (often available as reusable components), operating system components, and object and data management components.Page 220

步骤 3. 详细阐述所有未作为可重用组件获取的设计类。细化要求详细描述实现该类所需的所有接口、属性和操作。执行此任务时必须考虑设计启发法(例如,组件内聚性和耦合)。

Step 3. Elaborate all design classes that are not acquired as reusable components. Elaboration requires that all interfaces, attributes, and operations necessary to implement the class be described in detail. Design heuristics (e.g., component cohesion and coupling) must be considered as this task is conducted.

步骤 3a。指定类或组件协作时的消息详细信息。需求模型利用协作图来显示分析类如何相互协作。随着组件级设计的进行,有时通过指定系统内对象之间传递的消息结构来显示这些协作的细节是有用的。尽管此设计活动是可选的,但它可以用作显示系统内组件如何通信和协作的接口规范的先驱。

Step 3a. Specify message details when classes or components collaborate. The requirements model makes use of a collaboration diagram to show how analysis classes collaborate with one another. As component-level design proceeds, it is sometimes useful to show the details of these collaborations by specifying the structure of messages that are passed between objects within a system. Although this design activity is optional, it can be used as a precursor to the specification of interfaces that show how components within the system communicate and collaborate.

图 11.6展示了前面讨论的打印系统的简单协作图。ProductionJob、WorkOrderJobQueue三个对象协作准备打印作业以提交到生产流。消息在对象之间传递,如图中的箭头所示。在需求建模期间,消息被指定,如图所示。然而,随着设计的进行,每条消息都通过按以下方式扩展其语法来详细说明[Ben10a]:

Figure 11.6 illustrates a simple collaboration diagram for the printing system discussed earlier. Three objects, ProductionJob, WorkOrder, and JobQueue, collaborate to prepare a print job for submission to the production stream. Messages are passed between objects as illustrated by the arrows in the figure. During requirements modeling the messages are specified as shown in the figure. However, as design proceeds, each message is elaborated by expanding its syntax in the following manner [Ben10a]:

图11.6 消息协作

Figure 11.6 Collaboration diagram with messaging

[保护条件] 序列表达式(返回值) := 消息名称(参数列表)

[guard condition] sequence expression (return value) := message name (argument list)

其中[保护条件]是用对象约束语言(OCL)5编写的,并指定在发送消息之前必须满足的任何条件集;序列表达式是一个整数值(或其他排序指示符,例如3.1.2),指示消息发送的顺序;(返回值)是消息调用的操作返回的信息的名称;消息名称标识要调用的操作;(参数列表) 是传递给操作的属性列表。

where a [guard condition] is written in Object Constraint Language (OCL)5 and specifies any set of conditions that must be met before the message can be sent; sequence expression is an integer value (or other ordering indicator, e.g., 3.1.2) that indicates the sequential order in which a message is sent; (return value) is the name of the information that is returned by the operation invoked by the message; message name identifies the operation that is to be invoked; and (argument list) is the list of attributes that are passed to the operation.

第221页步骤 3b。为每个组件确定适当的接口。在组件级设计的背景下,UML 接口是“一组外部可见(即公共)操作”。该接口不包含内部结构,它没有属性,没有关联。。”。[本10a]。更正式地说,接口相当于抽象类,它提供设计类之间的受控连接。接口的详细说明如图 11.1所示。为设计类定义的操作被分类为一个或多个抽象类。抽象类(接口)中的每个操作都应该是内聚的;也就是说,它应该表现出专注于一项有限功能或子功能的处理。

Page 221Step 3b. Identify appropriate interfaces for each component. Within the context of component-level design, a UML interface is “a group of externally visible (i.e., public) operations. The interface contains no internal structure, it has no attributes, no associations . . .” [Ben10a]. Stated more formally, an interface is the equivalent of an abstract class that provides a controlled connection between design classes. The elaboration of interfaces is illustrated in Figure 11.1. The operations defined for the design class are categorized into one or more abstract classes. Every operation within the abstract class (the interface) should be cohesive; that is, it should exhibit processing that focuses on one limited function or subfunction.

参考图11.1,可以说接口initializeJob没有表现出足够的内聚性。它执行三个不同的子功能——建立工作订单、检查作业优先级以及将作业传递到生产。接口设计应该重构。一种方法可能是重新检查设计类并定义一个新类WorkOrder,该类将负责与工作订单组装相关的所有活动。操作buildWorkOrder()成为该类的一部分。类似地,我们可以定义一个包含checkPriority()操作的JobQueue类。ProductionJob类将包含与要传递到生产设施的生产作业相关的所有信息。接口initializeJob将采用如图11.7所示的形式。接口initiateJob现在是内聚的,专注于一个功能。与ProductionJob、WorkOrderJobQueue关联的接口同样是单一的。

Referring to Figure 11.1, it can be argued that the interface initiateJob does not exhibit sufficient cohesion. It performs three different subfunctions—building a work order, checking job priority, and passing a job to production. The interface design should be refactored. One approach might be to reexamine the design classes and define a new class WorkOrder that would take care of all activities associated with the assembly of a work order. The operation buildWorkOrder() becomes a part of that class. Similarly, we might define a class JobQueue that would incorporate the operation checkPriority(). A class ProductionJob would encompass all information associated with a production job to be passed to the production facility. The interface initiateJob would then take the form shown in Figure 11.7. The interface initiateJob is now cohesive, focusing on one function. The interfaces associated with ProductionJob, WorkOrder, and JobQueue are similarly single-minded.

11.7 重构 PrintJob 的接口和类定义

Figure 11.7 Refactoring interfaces and class definitions for PrintJob

步骤 3c。详细说明属性并定义实现它们所需的数据类型和数据结构。一般来说,用于定义属性的数据结构和类型是在用于实现的编程语言的上下文中定义的。UML 使用以下语法定义属性的数据类型:

Step 3c. Elaborate attributes and define data types and data structures required to implement them. In general, data structures and types used to define attributes are defined within the context of the programming language that is to be used for implementation. UML defines an attribute’s data type using the following syntax:

名称 : 类型表达式 = 初始值 {属性字符串}

name : type-expression = initial-value {property-string}

其中 name 是属性名称,type expression 是数据类型,初始值是创建对象时属性所采用的值,property-string 定义属性的属性或特征。

where name is the attribute name, type expression is the data type, initial value is the value that the attribute takes when an object is created, and property-string defines a property or characteristic of the attribute.

第222页在第一次组件级设计迭代期间,属性通常通过名称来描述。再次参考图11.1 , PrintJob的属性列表仅列出了属性的名称。然而,随着设计细化的进行,每个属性都使用所指出的 UML 属性格式来定义。例如,paperType-weight 的定义方式如下:

Page 222During the first component-level design iteration, attributes are normally described by name. Referring once again to Figure 11.1, the attribute list for PrintJob lists only the names of the attributes. However, as design elaboration proceeds, each attribute is defined using the UML attribute format noted. For example, paperType-weight is defined in the following manner:

paperType-weight: string = “A” {包含 4 个值中的 1 个 – A、B、C 或 D}

paperType-weight: string = “A” {contains 1 of 4 values – A, B, C, or D}

它将paperType-weight定义为一个初始化为值 A 的字符串变量,该变量可以采用集合 {A, B, C, D} 中的四个值之一。

which defines paperType-weight as a string variable initialized to the value A that can take on one of four values from the set {A, B, C, D}.

如果某个属性在多个设计类中重复出现,并且其结构相对复杂,则最好创建一个单独的类来容纳该属性。

If an attribute appears repeatedly across several design classes, and it has a relatively complex structure, it is best to create a separate class to accommodate the attribute.

步骤 3d。详细描述每个操作中的处理流程。这可以使用基于编程语言的伪代码或 UML 活动图来完成。每个软件组件都是通过应用逐步细化概念的多次迭代来详细说明的(第 9 章)。

Step 3d. Describe processing flow within each operation in detail. This may be accomplished using a programming language-based pseudocode or with a UML activity diagram. Each software component is elaborated through several iterations that apply the stepwise refinement concept (Chapter 9).

第一次迭代将每个操作定义为设计类的一部分。在每种情况下,操作的特征都应确保高内聚性;也就是说,操作应该执行单个目标功能或子功能。下一次迭代只不过是扩展操作名称。例如,图11.1中所示的computePaperCost()操作可以通过以下方式扩展:

The first iteration defines each operation as part of the design class. In every case, the operation should be characterized in a way that ensures high cohesion; that is, the operation should perform a single targeted function or subfunction. The next iteration does little more than expand the operation name. For example, the operation computePaperCost() noted in Figure 11.1 can be expanded in the following manner:

计算纸张成本(重量、尺寸、颜色):数字

computePaperCost (weight, size, color): numeric

这表明computePaperCost()需要属性重量、尺寸和颜色作为输入,并返回一个数值(实际上是美元值)作为输出。

This indicates that computePaperCost() requires the attributes weight, size, and color as input and returns a value that is numeric (actually a dollar value) as output.

如果实现computePaperCost()所需的算法简单且被广泛理解,则可能不需要进一步的设计阐述。进行编码的软件工程师将提供实施操作所需的详细信息。然而,如果算法更复杂或晦涩难懂,则在此阶段需要进一步的设计细化。图 11.8描述了computePaperCost() 的UML 活动图当活动图用于组件级设计规范时,它们通常以比源代码稍高的抽象级别表示。

If the algorithm required to implement computePaperCost() is simple and widely understood, no further design elaboration may be necessary. The software engineer who does the coding will provide the detail necessary to implement the operation. However, if the algorithm is more complex or arcane, further design elaboration is required at this stage. Figure 11.8 depicts a UML activity diagram for computePaperCost(). When activity diagrams are used for component-level design specification, they are generally represented at a level of abstraction that is somewhat higher than source code.

11.8computePaperCost ( )的 UML 活动图

Figure 11.8 UML activity diagram for computePaperCost()

步骤 4. 描述持久数据源(数据库和文件)并确定管理它们所需的类。数据库和文件通常超越单个组件的设计描述。在大多数情况下,这些持久数据存储最初被指定为架构设计的一部分。然而,随着设计细化的进行,提供有关这些持久数据源的结构和组织的更多详细信息通常很有用。

Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them. Databases and files normally transcend the design description of an individual component. In most cases, these persistent data stores are initially specified as part of architectural design. However, as design elaboration proceeds, it is often useful to provide additional detail about the structure and organization of these persistent data sources.

步骤 5. 开发并详细阐述类或组件的行为表示。UML 状态图被用作需求模型的一部分,以表示系统的外部可观察行为以及各个分析类的更本地化的行为。在组件级设计期间,有时需要对设计类的行为进行建模。

Step 5. Develop and elaborate behavioral representations for a class or component. UML state diagrams were used as part of the requirements model to represent the externally observable behavior of the system and the more localized behavior of individual analysis classes. During component-level design, it is sometimes necessary to model the behavior of a design class.

对象的动态行为(程序执行时设计类的实例化)受到外部事件和对象当前状态(行为模式)的影响。要了解对象的动态行为,您应该检查与设计类整个生命周期相关的所有用例。这些用例提供的信息可帮助您描述影响对象的事件以及对象随着时间的推移和事件发生而所处的状态。状态之间的转换(由事件驱动)使用 UML 状态图 [Ben10a] 表示,如图11.9所示。第223页

The dynamic behavior of an object (an instantiation of a design class as the program executes) is affected by events that are external to it and the current state (mode of behavior) of the object. To understand the dynamic behavior of an object, you should examine all use cases that are relevant to the design class throughout its life. These use cases provide information that helps you to delineate the events that affect the object and the states in which the object resides as time passes and events occur. The transitions between states (driven by events) is represented using a UML statechart [Ben10a], as illustrated in Figure 11.9.Page 223

图11.9 PrintJob 类的状态图片

Figure 11.9 Statechart fragment for PrintJob class

第224页从一种状态(由圆角矩形表示)到另一种状态的转换发生在以下形式的事件之后:

Page 224The transition from one state (represented by a rectangle with rounded corners) to another occurs following an event that takes the form of:

事件名称(参数列表)[保护条件]/动作表达式

Event-name (parameter-list) [guard-condition] / action expression

其中 event-name 标识事件,parameter-list 包含与事件关联的数据,guard-condition 用对象约束语言 (OCL) 编写,并指定事件发生之前必须满足的条件,而 action 表达式定义转换发生时发生的动作。

where event-name identifies the event, parameter-list incorporates data that are associated with the event, guard-condition is written in Object Constraint Language (OCL) and specifies a condition that must be met before the event can occur, and action expression defines an action that occurs as the transition takes place.

第225页参考图11.9,每个状态可以分别定义当发生进入该状态的转变和发生离开该状态的转变时发生的进入/和退出/动作在大多数情况下,这些操作对应于与正在建模的类相关的操作。do /指示符提供了一种用于指示在状态中发生的活动的机制,而include/指示符提供了一种通过在状态定义中嵌入更多状态图细节来详细说明行为的方法。

Page 225Referring to Figure 11.9, each state may define entry/ and exit/ actions that occur as transition into the state occurs and as transition out of the state occurs, respectively. In most cases, these actions correspond to operations that are relevant to the class that is being modeled. The do/ indicator provides a mechanism for indicating activities that occur while in the state, and the include/ indicator provides a means for elaborating the behavior by embedding more statechart detail within the definition of a state.

值得注意的是,行为模型通常包含在其他设计模型中并不立即明显的信息。例如,仔细检查图 11.9中的状态图表明, PrintJob类的动态行为取决于两个客户的批准,因为打印作业的成本和计划数据已导出。如果没有批准(保护条件确保客户有权批准),则无法提交打印作业,因为无法达到 SubmitJob状态

It is important to note that the behavioral model often contains information that is not immediately obvious in other design models. For example, careful examination of the statechart in Figure 11.9 indicates that the dynamic behavior of the PrintJob class is contingent upon two customer approvals as costs and schedule data for the print job are derived. Without approvals (the guard condition ensures that the customer is authorized to approve), the print job cannot be submitted because there is no way to reach the submittingJob state.

步骤 6. 详细阐述部署图以提供额外的实施细节。部署图(第 9 章)用作架构设计的一部分,并以描述符形式表示。在这种形式中,主要系统功能在容纳它们的计算环境的上下文中表示(通常作为子系统)。

Step 6. Elaborate deployment diagrams to provide additional implementation detail. Deployment diagrams (Chapter 9) are used as part of architectural design and are represented in descriptor form. In this form, major system functions are represented (often as subsystems) within the context of the computing environment that will house them.

在组件级设计过程中,可以详细说明部署图来表示组件关键包的位置。然而,组件通常不会在组件图中单独表示。这样做的原因是为了避免图表的复杂性。在某些情况下,部署图此时会被详细阐述为实例形式。这意味着将指定将使用的特定硬件和操作系统环境,并指示该环境中组件包的位置。

During component-level design, deployment diagrams can be elaborated to represent the location of key packages of components. However, components generally are not represented individually within a component diagram. The reason for this is to avoid diagrammatic complexity. In some cases, deployment diagrams are elaborated into instance form at this time. This means that the specific hardware and operating system environment(s) that will be used is (are) specified and the location of component packages within this environment is indicated.

步骤 7. 重构每个组件级设计表示并始终考虑替代方案。在本书中,我们强调设计是一个迭代的过程。您创建的第一个组件级模型将不如您应用于模型的第n次迭代那样完整、一致或准确。在进行设计工作时进行重构至关重要。

Step 7. Refactor every component-level design representation and always consider alternatives. Throughout this book, we emphasize that design is an iterative process. The first component-level model you create will not be as complete, consistent, or accurate as the nth iteration you apply to the model. It is essential to refactor as design work is conducted.





此外,您不应该出现视野狭隘的情况。总是有替代的设计解决方案,最好的设计师在确定最终设计模型之前会考虑所有(或大部分)这些解决方案。使用第 9 章和本章中介绍的设计原则和概念,开发替代方案并仔细考虑每个方案。

In addition, you should not suffer from tunnel vision. There are always alternative design solutions, and the best designers consider all (or most) of them before settling on the final design model. Develop alternatives and consider each carefully, using the design principles and concepts presented in Chapter 9 and in this chapter.

11.4 专门的组件级设计

11.4 Specialized Component-Level Design

有多种编程语言和多种方法来创建实现软件架构设计所需的组件。本章描述的原则为设计组件提供了一般建议。许多软件产品需要使用专门的程序开发环境,以便将其部署到目标最终用户设备(例如手机或数字助理)上。在本节中,我们概述了一些专门的组件设计技术。第226页

There are many programming languages and many ways to create the components required to implement a software architectural design. The principles described in this chapter provide general advice for designing components. Many software products require the use of specialized program development environments to allow their deployment on targeted end user devices such as cell phones or digital assistants. In this section, we present overviews of some specialized component design techniques.Page 226

11.4.1 WebApp 的组件级设计

11.4.1 Component-Level Design for WebApps

当考虑基于 Web 的系统和应用程序 (WebApps) 时,内容和功能之间的界限通常是模糊的。因此,我们有理由问:什么是 WebApp 组件?

The boundary between content and function is often blurred when Web-based systems and applications (WebApps) are considered. Therefore, it is reasonable to ask: What is a WebApp component?

在本章中,WebApp 组件是 (1) 一个定义明确的内聚函数,用于操纵内容或为最终用户提供计算或数据处理,或者 (2) 一个内聚的内容和功能包,为最终用户提供一些所需的能力。因此,WebApp 的组件级设计通常包含内容设计和功能设计的元素。

In the context of this chapter, a WebApp component is (1) a well-defined cohesive function that manipulates content or provides computational or data processing for an end user or (2) a cohesive package of content and functionality that provides the end user with some required capability. Therefore, component-level design for WebApps often incorporates elements of content design and functional design.

组件级别的内容设计重点关注内容对象以及将它们打包以呈现给 WebApp 最终用户的方式。组件级别的内容设计形式应根据要构建的 WebApp 的特征进行调整。在许多情况下,内容对象不需要组织为组件,并且可以单独操作。然而,随着(Web 应用程序、内容对象及其相互关系)的大小和复杂性的增长,可能有必要以允许更轻松地引用和设计操作的方式组织内容。6此外,如果内容是高度动态的(例如,在线拍卖网站的内容),那么建立一个包含内容组件的清晰的结构模型就变得很重要。

Content design at the component level focuses on content objects and the ways they may be packaged for presentation to a WebApp end user. The formality of content design at the component level should be tuned to the characteristics of the WebApp to be built. In many cases, content objects need not be organized as components and can be manipulated individually. However, as the size and complexity (of the WebApp, content objects, and their interrelationships) grows, it may be necessary to organize content in a way that allows easier reference and design manipulation.6 In addition, if content is highly dynamic (e.g., the content for an online auction site), it becomes important to establish a clear structural model that incorporates content components.

可能成为电子商务 Web 应用程序一部分的组件的一个很好的例子是“购物车”。购物车为电子商务客户提供了一种在结账前存储和查看所选商品的便捷方式。然后,他们可以在电子商务会话结束时通过单笔交易来支付他们的选择。只需编辑其内容模型,即可在多个 Web 商店应用程序中重复使用精心设计的购物车。

A good example of a component that might be part of an e-commerce WebApp is the “shopping cart.” A shopping cart provides a convenient way for e-commerce customers to store and review their selected items prior to checking out. They can then pay for their selections with a single transaction at the end of their e-commerce session. A carefully designed shopping cart can be reused in several Web store applications by simply editing its content model.

WebApp 功能可以作为与信息架构并行开发的一系列组件来提供,以确保一致性。前面描述的购物车组件包含内容和算法元素。您首先考虑需求模型和初始信息架构。接下来,您将检查功能如何影响用户与应用程序的交互、显示的信息以及执行的用户任务。

WebApp functionality can be delivered as a series of components developed in parallel with the information architecture to ensure consistency. The shopping cart component described previously contains both content and algorithmic elements. You begin by considering both the requirements model and the initial information architecture. Next, you examine how functionality affects the user’s interaction with the application, the information that is presented, and the user tasks that are conducted.

在架构设计过程中,WebApp 内容和功能相结合以创建功能架构。功能架构是WebApp功能域的表示,描述了WebApp中的关键功能组件以及这些组件如何相互交互。

During architectural design, WebApp content and functionality are combined to create a functional architecture. A functional architecture is a representation of the functional domain of the WebApp and describes the key functional components in the WebApp and how these components interact with each other.

11.4.2 移动应用的组件级设计

11.4.2 Component-Level Design for Mobile Apps

移动应用程序通常使用多层架构构建,包括用户界面层、业务层和数据层。如果您将移动应用程序构建为基于 Web 的瘦客户端,则驻留在移动设备上的唯一组件是实现用户界面所需的组件。一些移动应用程序可能包含在移动设备上实现业务和/或数据层所需的组件,使这些层受到设备物理特性的限制。

Mobile apps are typically structured using multilayered architectures, including a user interface layer, a business layer, and a data layer. If you are building a mobile app as a thin Web-based client, the only components residing on a mobile device are those required to implement the user interface. Some mobile apps may incorporate the components required to implement the business and/or data layers on the mobile device, subjecting these layers to the limitations of the physical characteristics of the device.

第227页首先考虑用户界面层,重要的是要认识到较小的显示区域要求设计者在选择要显示的内容(文本和图形)时更具选择性。针对特定用户组定制内容并仅显示每个组需要的内容可能会有所帮助。业务层和数据层通常通过组合Web或云服务组件来实现。如果提供业务和数据服务的组件完全驻留在移动设备上,那么连接问题就不是一个重要问题。在设计需要访问驻留在网络服务器上的当前应用程序数据的组件时,必须考虑间歇性(或缺失)的 Internet 连接。

Page 227Considering the user interface layer first, it is important to recognize that a small display area requires the designer to be more selective in choosing the content (text and graphics) to be displayed. It may be helpful to tailor the content to a specific user group(s) and display only what each group needs. The business and data layers are often implemented by composing Web or cloud service components. If the components providing business and data services reside entirely on the mobile device, connectivity issues are not a significant concern. Intermittent (or missing) Internet connectivity must be considered when designing components that require access to current application data that reside on a networked server.

如果将桌面应用程序移植到移动设备,则可能需要审查业务层组件,以确定它们是否满足新平台所需的非功能性要求(例如,安全性、性能、可访问性)。目标移动设备可能缺乏必要的处理器速度、内存或显示空间。第 13 章更详细地讨论了移动应用程序的设计。

If a desktop application is being ported to a mobile device, the business-layer components may need to be reviewed to see if they meet nonfunctional requirements (e.g., security, performance, accessibility) required by the new platform. The target mobile device may lack the necessary processor speed, memory, or display real estate. The design of mobile applications is considered in greater detail in Chapter 13.

移动应用程序中的组件示例可能是通常为手机和平板电脑设计的单窗口全屏用户界面 (UI)。通过精心设计,移动应用程序可以感知移动设备的显示特性并调整其外观,以确保文本、图形和 UI 控件在许多不同的屏幕类型上正常运行。这使得移动应用程序能够在所有平台上以类似的方式运行,而无需重新编程。

An example of a component in a mobile application might be the single-window full-screen user interface (UI) typically designed for phones and tablets. With careful design it may be possible to allow the mobile app to sense the display characteristics of the mobile device and adapt its appearance to ensure that text, graphics, and UI controls function correctly on many different screen types. This allows the mobile app to function in similar ways on all platforms, without having to be reprogrammed.

11.4.3 设计传统组件

11.4.3 Designing Traditional Components

传统软件组件的组件级设计的基础形成于 20 世纪 60 年代初期,并通过 Edsger Dijkstra([Dij65]、[Dij76b])和其他人(例如,[Boh66])的工作得到巩固。传统的软件组件实现一个处理元素,用于解决问题域中的功能或子功能或基础设施域中的某些功能。这些传统组件通常称为函数、模块、过程或子例程。传统组件不像面向对象组件那样封装数据。大多数程序员在开发新的软件产品时经常使用函数库和数据结构模板。

The foundations of component-level design for traditional software components were formed in the early 1960s and were solidified with the work of Edsger Dijkstra ([Dij65], [Dij76b]) and others (e.g., [Boh66]). A traditional software component implements an element of processing that addresses a function or subfunction in the problem domain or some capability in the infrastructure domain. Often these traditional components are called functions, modules, procedures, or subroutines. Traditional components do not encapsulate data in the same way that object-oriented components do. Most programmers make frequent use of function libraries and data structure templates when developing new software products.

在 20 世纪 60 年代末,Dijkstra 和其他人提出使用一组受约束的逻辑结构,从中可以形成任何程序。这些结构强调“功能域的维护”。也就是说,每个结构都有一个可预测的逻辑结构,从顶部进入,从底部退出,使读者能够更轻松地遵循程序流程。

In the late 1960s, Dijkstra and others proposed the use of a set of constrained logical constructs from which any program could be formed. The constructs emphasized “maintenance of functional domain.” That is, each construct had a predictable logical structure and was entered at the top and exited at the bottom, enabling a reader to follow procedural flow more easily.

结构是序列、条件和重复。序列实现了任何算法规范中必不可少的处理步骤。条件为基于某些逻辑发生的选定处理提供了便利,并且重复允许循环。这三个构造是结构化编程的基础——结构化编程是一种重要的组件级设计技术。

The constructs are sequence, condition, and repetition. Sequence implements processing steps that are essential in the specification of any algorithm. Condition provides the facility for selected processing based on some logical occurrence, and repetition allows for looping. These three constructs are fundamental to structured programming—an important component-level design technique.

提出结构化构造是为了将软件的过程设计限制为少量可预测的逻辑结构。复杂性度量(第 23 章)表明结构化构造的使用降低了程序复杂性,从而增强了可读性、可测试性和可维护性。使用有限数量的逻辑结构也有助于人类理解过程,心理学家称之为分块。要理解此过程,请考虑您阅读本页的方式。您不会阅读单个字母,而是识别形成单词或短语的模式或字母块。结构化构造是逻辑块,允许读者识别模块的过程元素,而不是逐行阅读设计或代码。当遇到易于识别的逻辑模式时,理解力就会增强。第228页

The structured constructs were proposed to limit the procedural design of software to a small number of predictable logical structures. Complexity metrics (Chapter 23) indicate that the use of the structured constructs reduces program complexity and thereby enhances readability, testability, and maintainability. The use of a limited number of logical constructs also contributes to a human understanding process that psychologists call chunking. To understand this process, consider the way in which you are reading this page. You do not read individual letters but rather recognize patterns or chunks of letters that form words or phrases. The structured constructs are logical chunks that allow a reader to recognize procedural elements of a module, rather than reading the design or code line by line. Understanding is enhanced when readily recognizable logical patterns are encountered.Page 228

任何程序,无论应用领域或技术复杂性如何,都可以仅使用这三种结构化构造来设计和实现。然而,应该指出的是,仅教条地使用这些结构有时会导致实际困难。

Any program, regardless of application area or technical complexity, can be designed and implemented using only the three structured constructs. It should be noted, however, that dogmatic use of only these constructs can sometimes cause practical difficulties.

11.4.4 基于组件的开发

11.4.4 Component-Based Development

在软件工程中,重用是一个既古老又新颖的想法。从计算的最初时代起,程序员就开始重用想法、抽象和流程,但早期的重用方法是临时的。如今,复杂、高质量的基于计算机的系统必须在非常短的时间内构建,并且需要更有组织的重用方法。

In software engineering, reuse is an idea both old and new. Programmers have reused ideas, abstractions, and processes since the earliest days of computing, but the early approach to reuse was ad hoc. Today, complex, high-quality computer-based systems must be built in very short time periods and demand a more organized approach to reuse.

基于组件的软件工程(CBSE)是一个强调使用可重用软件组件设计和构建基于计算机的系统的过程(图11.10)。考虑到这个描述,就会出现许多问题。是否可以通过从可重用软件组件的目录中组装复杂的系统来构建复杂的系统?这能否以经济高效的方式实现?能否建立适当的激励措施来鼓励软件工程师重用而不是重新发明?管理层是否愿意承担与创建可重用软件组件相关的额外费用?是否可以创建实现重用所需的组件库,以便需要它的人可以访问它?需要的人能否找到现有组件?这些问题的答案越来越多地都是肯定的。

Component-based software engineering (CBSE) is a process that emphasizes the design and construction of computer-based systems using reusable software components (Figure 11.10). Considering this description, many questions arise. Is it possible to construct complex systems by assembling them from a catalog of reusable software components? Can this be accomplished in a cost- and time-effective manner? Can appropriate incentives be established to encourage software engineers to reuse rather than reinvent? Is management willing to incur the added expense associated with creating reusable software components? Can a library of components necessary to accomplish reuse be created in a way that makes it accessible to those who need it? Can existing components be found by those who need them? Increasingly, the answer to each of these questions is yes.

图11.10 基于组件的软件设计

Figure 11.10 Component-based software design

图 11.10显示了 CBSE 的原理步骤。您从系统需求开始,并将其细化到可以识别所需组件的程度。然后,开发人员将搜索存储库以查看是否有任何组件已经存在。每个组件都有自己的后置条件和前置条件。识别后置条件与系统要求匹配的组件,并检查每个组件的前提条件。如果满足先决条件,则选择该组件包含在当前构建中。当无法选择组件时,开发人员必须决定是修改需求还是修改与原始需求最匹配的组件。这通常是一个迭代过程,一直持续到可以使用现有或新创建的组件的组合来实现架构设计为止。

Figure 11.10 shows the principle steps in CBSE. You start with the system requirements and refine them to the point that needed components can be identified. The developers would then search the repository to see if any of the components already exist. Each component has its own postconditions and preconditions. Components whose postconditions match a system requirement are identified, and the preconditions of each component are checked. If the preconditions are satisfied, the component is selected for inclusion in the current build. When no components can be selected, the developers must decide whether to modify the requirements or modify a component that most closely matches the original requirements. This is often an iterative process that continues until the architecture design can be implemented, using a combination of existing or newly created components.

第229页考虑开发自动驾驶汽车的任务,无论是在现实生活中还是在视频游戏中。这些复杂系统的软件通常是通过组合多个可重用组件来创建的,其中这些组件提供不同的模块化服务。通常,它们会包含许多软件组件:管理障碍物检测的组件、规划或导航组件、管理决策的人工智能组件以及控制车辆运动或制动的某种类型的组件。由于这些类型的软件模块有可能在许多不同的车辆中使用,因此希望能够将它们容纳在组件库中。

Page 229Consider the task of developing autonomous vehicles, either in real life or a video game. The software for these complex systems is typically created by combing several reusable components, where the components provide distinct modular services. Typically they would include many software components: a component that manages obstacle detection, a planning or navigation component, an artificial intelligence component to manage decision making, and a component of some type controlling vehicle movement or braking. Because these types of software modules have the potential to be used in many different vehicles, it would be desirable to be able to house them in a library of components.

由于 CBSE 利用现有组件,因此可以缩短开发时间并提高质量。从业者 [Vit03] 通常将 CBSE 归因于以下优势:

Because CBSE makes use of existing components, it can shorten development time and increase quality. Practitioners [Vit03] often attribute the following advantages to CBSE:

  • 缩短交货时间。从现有组件池构建完整的应用程序会更快。

  • Reduced lead time. It is faster to build complete applications from a pool of existing components.

  • 更高的投资回报 (ROI)。有时,通过购买组件而不是在内部重新开发相同的功能可以实现节省。

  • Greater return on investment (ROI). Sometimes savings can be realized by purchasing components rather than redeveloping the same functionality in-house.

  • 杠杆化组件开发成本。在多个应用程序中重用组件可以将成本分摊到多个项目中。

  • Leveraged costs of developing components. Reusing components in multiple applications allows the costs to be spread over multiple projects.

  • 品质提升。组件在许多不同的应用程序中被重复使用和测试。

  • Enhanced quality. Components are reused and tested in many different applications.

  • 维护基于组件的应用程序。通过精心设计,可以相对容易地用新的或增强的组件替换过时的组件。

  • Maintenance of component-based applications. With careful engineering, it can be relatively easy to replace obsolete components with new or enhanced components.

在 CBSE 中使用组件并非没有风险。其中一些包括以下 [Kau11]:

Use of components in CBSE is not without risks. Several of these include the following [Kau11]:

  • 元件选择风险。很难预测黑盒组件的组件行为,或者用户需求到组件架构设计的映射可能很差。

  • Component selection risks. It is difficult to predict component behavior for black-box components, or there may be poor mapping of user requirements to the component architectural design.

  • 组件集成风险。组件之间缺乏互操作性标准;这通常需要创建“包装代码”来连接组件。

  • Component integration risks. There is a lack of interoperability standards between components; this often requires the creation of “wrapper code” to interface components.

  • 质量风险。对组件进行的未知设计假设会使测试变得更加困难,这可能会影响系统的安全性、性能和可靠性。

  • Quality risks. Unknown design assumptions made for the components makes testing more difficult, and this can affect system safety, performance, and reliability.

  • 安全风险。系统可能会以意想不到的方式使用,并且以未经测试的组合集成组件可能会导致系统漏洞。

  • Security risks. A system can be used in unintended ways, and system vulnerabilities can be caused by integrating components in untested combinations.

  • 系统演化风险。更新的组件可能与用户要求不兼容或包含其他未记录的功能。

  • System evolution risks. Updated components may be incompatible with user requirements or contain additional undocumented features.

广泛的组件重用面临的挑战之一是架构不匹配[Gar09a]——关于组件及其操作环境的假设之间的不兼容。7这些假设通常侧重于组件控制模型、组件连接(接口)的性质、架构基础设施本身以及构建过程的性质。第230页

One of the challenges facing widespread component reuse is architectural mismatch [Gar09a]—incompatibilities between assumptions made about components and their operating environments.7 These assumptions often focus on the component control model, the nature of the component connections (interfaces), the architectural infrastructure itself, and the nature of the construction process.Page 230

如果明确记录了利益相关者的假设,则可以及早发现架构不匹配。此外,风险驱动流程模型的使用强调了早期架构原型的定义并指出了不匹配的领域。如果不使用包装器或适配器等机制,修复架构不匹配通常非常困难。8有时需要完全重新设计组件接口或组件本身以消除耦合问题。

Early detection of architectural mismatch can occur if stakeholder assumptions are explicitly documented. In addition, the use of a risk-driven process model emphasizes the definition of early architectural prototypes and points to areas of mismatch. Repairing architectural mismatch is often very difficult without making use of mechanisms like wrappers or adapters.8 Sometimes it is necessary to completely redesign a component interface or the component itself to remove coupling issues.

11.5 组件重构

11.5 Component Refactoring

抽象、隐藏、功能独立、细化和结构化编程等设计概念,以及面向对象的方法、测试和软件质量保证(SQA)都有助于创建更容易重构的软件组件。大多数开发人员都同意重构组件以提高质量是一种很好的做法。通常很难让管理层相信花费资源修复正常工作的组件而不是向其添加新功能很重要。

Design concepts such as abstraction, hiding, functional independence, refinement, and structured programming, along with object-oriented methods, testing, and software quality assurance (SQA) all contribute to the creation of software components that will be easier to refactor. Most developers would agree that refactoring components to improve quality is a good practice. It is often hard to convince management that it is important to expend resources fixing components that are working correctly instead of adding new functionality to them.

在本书中,我们重点关注系统组件的增量设计和交付。尽管没有可量化的关系来描述代码更改对架构质量的影响,但大多数软件工程师都认为,随着时间的推移,对系统的大量更改可能会导致在代码库中创建有问题的结构。如果不能解决这些问题,就会增加与软件系统相关的技术债务(第 9 章)。减少这种技术债务通常涉及架构重构,开发人员通常认为这既昂贵又危险。您不能简单地将大型组件分解为较小的组件,并期望看到内聚力的自动增加和耦合的减少,从而减少技术债务。

In this book, we focus on the incremental design and delivery of system components. Although there is no quantifiable relationship describing the effects of code changes on architectural quality, most software engineers agree that over time large numbers of changes to a system can lead to the creation of problematic structures in the code base. Failing to address these problems increases the amount of technical debt (Chapter 9) associated with the software system. Reducing this technical debt often involves architectural refactoring, which is generally perceived by developers as both costly and risky. You cannot simply break up large components into smaller components and expect to see an automatic increase in cohesion and a reduction in coupling that will reduce technical debt.

大型软件系统可能有数千个组件。利用数据挖掘技术来识别重构机会对这项工作非常有益。自动化工具可以分析系统组件的源代码,并根据已知与架构问题相关的通用设计规则向开发人员提出重构建议。但仍然由开发人员及其经理决定接受哪些更改以及忽略哪些更改[Lin16]。

Large software systems may have thousands of components. Making use of datamining techniques to identify refactoring opportunities can be very beneficial to this work. Automated tools can analyze the source code of system components and make refactoring recommendations to developers, based on generic design rules known to be associated with architectural problems. But it is still up to the developers and their managers to decide which changes to accept and which to ignore [Lin16].

事实证明,软件系统中许多容易出错的组件在架构上都是相互连接的。这些有缺陷的架构连接往往会在它们之间传播缺陷并积累高昂的维护成本。如果能够自动识别系统中存在的技术债务以及相关的维护成本,那么就更容易说服开发人员和管理人员花时间重构这些组件。完成此类工作需要检查系统组件的变更历史[Xia16]。例如,如果总是同时从代码存储库中检出两个或三个组件进行修改,则可能表明这些组件具有共同的设计缺陷。

It turns out that many of the error-prone components in a software system are architecturally connected to one another. These flawed architectural connections tend to propagate defects among themselves and accumulate high maintenance costs. If it was possible to automatically identify the technical debt present in the system and the associated maintenance costs, it would be easier to convince developers and managers to spend time refactoring these components. Accomplishing this type of work requires examining the change histories of the system components [Xia16]. For example, if two or three components are always checked out of the code repository for modification at the same time, it may suggest the components share a common design defect.

第231页

Page 231

11.6 总结

11.6 Summary

组件级设计过程包含一系列活动,这些活动慢慢降低了软件表示的抽象级别。组件级设计最终在接近代码的抽象级别上描述软件。

The component-level design process encompasses a sequence of activities that slowly reduces the level of abstraction with which software is represented. Component-level design ultimately depicts the software at a level of abstraction that is close to code.

根据要开发的软件的性质,可以采用三种不同的组件级设计视图。面向对象的观点侧重于来自问题和基础设施领域的设计类的详细阐述。传统的观点细化了三种不同类型的组件或模块:控制模块、问题域模块和基础设施模块。在这两种情况下,都应用了产生高质量软件的基本设计原则和概念。从过程的角度考虑时,组件级设计利用了可重用的软件组件和设计模式,它们是基于组件的软件工程的关键元素。

Three different views of component-level design may be taken, depending on the nature of the software to be developed. The object-oriented view focuses on the elaboration of design classes that come from both the problem and infrastructure domain. The traditional view refines three different types of components or modules: control modules, problem domain modules, and infrastructure modules. In both cases, basic design principles and concepts that lead to high-quality software are applied. When considered from a process viewpoint, component-level design draws on reusable software components and design patterns that are pivotal elements of component-based software engineering.

在详细阐述类时,有几个重要的原则和概念指导设计者。开闭原则和依赖倒置原则中包含的思想,以及耦合和内聚等概念,指导软件工程师构建可测试、可实现和可维护的软件组件。为了在这种情况下进行组件级设计,需要通过指定消息传递细节、识别适当的接口、详细说明属性、定义实现它们的数据结构、描述每个操作内的处理流程以及表示类或组件级的行为来详细说明类。在任何情况下,设计迭代(重构)都是一项重要的活动。

Several important principles and concepts guide the designer as classes are elaborated. Ideas encompassed in the open-closed principle and the dependency inversion principle, along with concepts such as coupling and cohesion, guide the software engineer in building testable, implementable, and maintainable software components. To conduct component-level design in this context, classes are elaborated by specifying messaging details, identifying appropriate interfaces, elaborating attributes, and defining data structures to implement them, describing processing flow within each operation, and representing behavior at a class or component level. In every case, design iteration (refactoring) is an essential activity.

传统的组件级设计需要足够详细地表示程序模块的数据结构、接口和算法,以指导编程语言源代码的生成。为了实现这一点,设计人员使用多种设计符号之一,以图形、表格或基于文本的格式表示组件级细节。

Traditional component-level design requires the representation of data structures, interfaces, and algorithms for a program module in sufficient detail to guide in the generation of programming language source code. To accomplish this, the designer uses one of several design notations that represent component-level detail in either graphical, tabular, or text-based formats.

WebApp 的组件级设计考虑了基于 Web 的系统将提供的内容和功能。组件级别的内容设计重点关注内容对象以及将它们打包以呈现给 WebApp 最终用户的方式。WebApp 的功能设计侧重于操作内容、执行计算、处理数据库查询以及与其他系统建立接口的处理功能。所有组件级设计原则和指南均适用。

Component-level design for WebApps considers both content and functionality as a Web-based system will deliver it. Content design at the component level focuses on content objects and the ways they may be packaged for presentation to a WebApp end user. Functional design for WebApps focuses on processing functions that manipulate content, perform computations, process database queries, and establish interfaces with other systems. All component-level design principles and guidelines apply.

移动应用程序的组件级设计利用多层架构,包括用户界面层、业务层和数据层。如果移动应用程序需要设计在移动设备上实现业务和/或数据层的组件,那么设备物理特性的限制就成为设计的重要约束。

Component-level design for mobile apps makes use of a multilayered architecture that includes a user interface layer, a business layer, and a data layer. If the mobile app requires the design of components that implement the business and/or data layers on the mobile device, the limitations of the physical characteristics of the device become important constraints on the design.

第232页结构化编程是一种过程设计哲学,它限制用于表示算法细节的逻辑构造的数量和类型。结构化编程的目的是帮助设计人员定义不太复杂的算法,从而更容易阅读、测试和维护。

Page 232Structured programming is a procedural design philosophy that constrains the number and type of logical constructs used to represent algorithmic detail. The intent of structured programming is to assist the designer in defining algorithms that are less complex and therefore easier to read, test, and maintain.

基于组件的软件工程为应用程序域识别、构建、编目和传播一组软件组件。然后对这些组件进行资格认证、调整和集成,以便在新系统中使用。可重用组件应该在为每个应用程序域建立标准数据结构、接口协议和程序体系结构的环境中设计。

Component-based software engineering identifies, constructs, catalogs, and disseminates a set of software components for an application domain. These components are then qualified, adapted, and integrated for use in a new system. Reusable components should be designed within an environment that establishes standard data structures, interface protocols, and program architectures for each application domain.

问题与思考点

Problems and Points to Ponder

11.1. 组件一词有时很难定义。首先提供一个通用的定义,然后为面向对象和传统软件提供更明确的定义。最后,选择您熟悉的三种编程语言,并说明每种语言如何定义组件。

11.1. The term component is sometimes a difficult one to define. First provide a generic definition, and then provide more explicit definitions for object-oriented and traditional software. Finally, pick three programming languages with which you are familiar and illustrate how each defines a component.

11.2. 为什么控制组件在传统软件中是必需的,而在面向对象软件中通常不需要?

11.2. Why are control components necessary in traditional software and generally not required in object-oriented software?

11.3。用您自己的话描述 OCP。为什么创建用作组件之间接口的抽象很重要?

11.3. Describe the OCP in your own words. Why is it important to create abstractions that serve as an interface between components?

11.4。用你自己的话描述 DIP。如果设计师过于依赖具体内容会发生什么?

11.4. Describe the DIP in your own words. What might happen if a designer depends too heavily on concretions?

11.5。选择您最近开发的三个组件,并评估每个组件所表现出的凝聚力类型。如果您必须定义高内聚力的主要好处,它会是什么?

11.5. Select three components that you have developed recently, and assess the types of cohesion that each exhibits. If you had to define the primary benefit of high cohesion, what would it be?

11.6。选择您最近开发的三个组件,并评估每个组件所表现出的耦合类型。如果您必须定义低耦合的主要好处,它会是什么?

11.6. Select three components that you have developed recently, and assess the types of coupling that each exhibits. If you had to define the primary benefit of low coupling, what would it be?

11.7。开发 (1) 一个详细的设计类,(2) 接口描述,(3) 类内操作之一的活动图,以及 (4) 我们之前讨论过的 SafeHome 类之一的详细状态章节。

11.7. Develop (1) an elaborated design class, (2) interface descriptions, (3) an activity diagram for one of the operations within the class, and (4) a detailed statechart diagram for one of the SafeHome classes that we have discussed in earlier chapters.

11.8。什么是 WebApp 组件?

11.8. What is a WebApp component?

11.9。从小型软件组件中选择代码并使用活动图表示它。

11.9. Select the code from a small software component and represent it using an activity diagram.

11.10。为什么“分块”在组件级设计评审过程中很重要?

11.10. Why is “chunking” important during the component-level design review process?

1在某些情况下,一个组件可能包含单个类。

1 In some cases, a component may contain a single class.

2不熟悉 UML 表示法的读者请参阅附录 1。

2 Readers who are unfamiliar with UML notation should refer to Appendix 1.

3来自营销或客户组织(非技术类型)的人员不太可能检查详细的设计信息。

3 It is unlikely that someone from marketing or the customer organization (a nontechnical type) would examine detailed design information.

4一般来说,内聚程度越高,组件就越容易实现、测试和维护。

4 In general, the higher the level of cohesion, the easier the component is to implement, test, and maintain.

5 OCL 在附录 1 中进行了简要讨论。

5 OCL is discussed briefly in Appendix 1.

6内容组件也可以在其他 Web 应用程序中重用。

6 Content components can also be reused in other WebApps.

7这可能是多种形式的耦合造成的,应尽可能避免。

7 This can be a result of several forms of coupling that should be avoided whenever possible.

8适配器是一种软件设备,通过将服务请求转换为可以访问原始接口的形式,允许具有不兼容接口的客户端访问组件。

8 An adapter is a software device that allows a client with an incompatible interface to access a component by translating a request for service into a form that can access the original interface.

第233页

Page 233

章节

chapter

12用户体验设计

12 User Experience Design

我们生活在一个充满高科技产品的世界,几乎所有产品——消费电子产品、工业设备、汽车、企业系统、军事系统、移动应用程序、网络应用程序、视频游戏和虚拟现实模拟——都需要人类交互。如果产品要成功,它必须提供积极的用户体验(UX)。产品需要表现出良好的可用性——对人类使用高科技产品所提供的功能和特性的易用性和效率的定性衡量。当产品的指定用户包括在指定使用环境中的一系列残疾人时,产品应考虑可访问性考虑因素,例如辅助技术

We live in a world of high-technology products, and virtually all of them—consumer electronics, industrial equipment, automobiles, corporate systems, military systems, mobile apps, WebApps, video games, and virtual reality simulations—require human interaction. If a product is to be successful, it must provide a positive user experience (UX). The product needs to exhibit good usability—a qualitative measure of the ease and efficiency with which a human can employ the functions and features offered by the high-technology product. A product should incorporate accessibility considerations such as assistive technologies when its specified users include people with a range of disabilities within a specified context of use.

第234页在计算时代的前三十年,可用性并不是软件开发者最关心的问题。唐纳德·诺曼 [Nor88] 在他关于设计的经典著作中认为,是时候改变态度了:“为了制造适合人类的技术,有必要研究人类。但现在我们倾向于只研究技术。因此,人们必须服从技术。现在是扭转这一趋势的时候了,是时候创造出符合人们需求的技术了。”

Page 234For the first three decades of the computing era, usability was not a dominant concern among those who built software. In his classic book on design, Donald Norman [Nor88] argued that it was time for a change in attitude: “To make technology that fits human beings, it is necessary to study human beings. But now we tend to study only the technology. As a result, people are required to conform to technology. It is time to reverse this trend, time to make technology that conforms to people.”

当技术专家研究人类互动时,出现了两个主要问题。首先,确定了一组黄金规则第 12.2 节中讨论)。这些适用于人类与技术产品的所有交互。其次,定义了一组交互机制,使软件设计人员能够构建正确实施黄金规则的系统。这些交互机制统称为用户界面,消除了与人机界面相关的许多严重问题中的一些。但即使在今天,我们仍然会遇到难以学习、难以使用、令人困惑、违反直觉、无情的用户界面,而且在许多情况下,完全令人沮丧。然而,有人花费了时间和精力来构建这些界面,并且构建者不太可能故意制造这些问题。

As technologists studied human interaction, two dominant issues arose. First, a set of golden rules (discussed in Section 12.2) were identified. These applied to all human interaction with technology products. Second, a set of interaction mechanisms were defined to enable software designers to build systems that properly implemented the golden rules. These interaction mechanisms, collectively called the user interface, have eliminated some of the many egregious problems associated with human interfaces. But even today, we all encounter user interfaces that are difficult to learn, difficult to use, confusing, counterintuitive, unforgiving, and in many cases, totally frustrating. Yet, someone spent time and energy building each of these interfaces, and it is not likely that the builder created these problems purposely.

用户体验设计是一组增量过程活动,帮助开发团队和项目利益相关者专注于为软件产品的用户提供积极的体验。用户体验设计比用户界面设计和可用性或可访问性工程更广泛。如果要有效,它必须在项目生命周期的早期开始。等到项目结束才添加用户界面功能的开发人员不太可能为用户提供愉快的体验。

User experience design is a set of incremental process activities that help the development team and the project stakeholders focus on providing a positive experience for users of the software product. UX design is broader than user interface design and usability or accessibility engineering. It must begin early in the project life cycle if it is to be effective. Developers waiting until the end of a project to add user interface functionality are unlikely to provide a pleasurable experience for users.

在本章中,我们将重点讨论用户体验设计背景下的用户界面设计问题。希望更详细地介绍用户体验的读者应该阅读 Shneiderman [Shn16]、Nielsen [Nei93] 和 Norman [Nor13] 的书籍。

In this chapter we will focus on user interface design issues in the context of user experience design. Readers wishing a more detailed coverage of UX should examine books by Shneiderman [Shn16], Nielsen [Nei93], and Norman [Nor13].

12.1 用户体验设计元素

12.1 User Experience Design Elements

用户体验设计试图确保如果开发团队和其他利益相关者明确决定将软件的任何方面包含在最终候选版本中,则不会出现该软件的任何方面。这意味着在开发过程的每一步中都要考虑每一个合理的用户行为和期望。为了使打造积极的用户体验的任务更易于管理,Garret [Gar10] 建议将其分解为组成元素:策略、范围、结构、骨架和表面。这些组件元素和子组件之间的关系如图12.1所示。

User experience design tries to ensure that no aspect of your software appears in the final release candidate without the explicit decision of the development team and other stakeholders to include it. This means taking into account every reasonable user action and expectation during every step of the development process. To make the task of crafting a positive user experience more manageable, Garret [Gar10] suggests breaking it down into component elements: strategy, scope, structure, skeleton, and surface. The relationships among these component elements and subcomponents are show in Figure 12.1.

图12.1用户 体验设计元素

Figure 12.1 User experience design elements

对于软件产品开发,Garrett 的 UX 设计组织可以解释如下:

The Garrett’s organization of UX design can be interpreted as follows for software product development:

  • 战略。确定构成所有用户体验设计工作基础的用户需求和客户业务目标(第 12.4 节

  • Strategy. Identifies user needs and customer business goals that form the basis for all UX design work (Section 12.4)

  • 范围。包括实现与项目策略一致的功能集所需的功能和内容(例如信息、媒体、服务)要求

  • Scope. Includes both the functional and content (e.g., information, media, services) requirements needed to realize a feature set consistent with the project strategy

  • 第235页结构。包括交互设计[例如,系统如何响应用户操作(第12.1.2节)]和信息架构[例如,内容元素的组织(第12.1.1节)]

  • Page 235Structure. Consists of the interaction design [e.g., how the system reacts in response to user actions (Section 12.1.2)] and information architecture [e.g., the organization of the content elements (Section 12.1.1)]

  • 骨骼。由三个部分组成:信息设计(例如,以用户可以理解的方式呈现内容)、界面设计[例如,安排界面屏幕对象以允许用户使用系统功能(第 12.5 节)]、导航设计(例如,允许用户遍历信息架构的一组屏幕元素)

  • Skeleton. Comprised of three components: information design (e.g., presentation of content in a way to make it understandable to the user), interface design [e.g., arranging interface screen objects to allow the user to work with the system functionality (Section 12.5)], navigation design (e.g., the set of screen elements that allow users to traverse the information architecture)

  • 表面。向用户展示视觉设计或已完成项目的外观(第 12.1.4 节

  • Surface. Presents visual design or the appearance of the finished project to its users (Section 12.1.4)

软件工程师对用户体验设计的几个横切方面特别感兴趣:信息架构、用户交互设计、可用性工程和视觉设计。

Several cross-cutting aspects of UX design are of particular interest to software engineers: information architecture, user interaction design, usability engineering, and visual design.

12.1.1 信息架构

12.1.1 Information Architecture

作为架构设计师,必须识别信息(内容)架构和软件架构。术语信息架构用于表示可以更好地组织、标记、导航和搜索内容对象的结构。内容架构重点关注内容对象(或复合对象,例如屏幕或小部件)的呈现和导航结构方式。软件架构解决了应用程序的构建方式,以管理用户交互、处理内部处理任务、效果导航和呈现内容。

As an architectural designer, you must identify information (content) architecture and software architecture. The term information architecture is used to connote structures that lead to better organization, labeling, navigation, and searching of content objects. Content architecture focuses on the manner in which content objects (or composite objects such as screens or widgets) are structured for presentation and navigation. Software architecture addresses the manner in which the application is structured to manage user interaction, handle internal processing tasks, effect navigation, and present content.

架构设计(第 10 章)与为软件产品建立的目标、要呈现的内容、将访问的用户以及已建立的导航理念联系在一起。在大多数情况下,架构设计是与界面设计、美学设计和内容设计并行进行的。由于软件架构可能对导航有很大影响,因此在此设计操作期间做出的决策将影响导航设计期间进行的工作。在许多情况下,需要主题专家来帮助项目利益相关者组织内容项,以便产品用户有效地同化和遍历。第236页

Architectural design (Chapter 10) is tied to the goals established for a software product, the content to be presented, the users who will visit, and the navigation philosophy that has been established. In most cases, architecture design is conducted in parallel with interface design, aesthetic design, and content design. Because the software architecture may have a strong influence on navigation, the decisions made during this design action will influence work conducted during navigation design. In many cases, a subject matter expert is needed to help project stakeholders organize the content items for efficient assimilation and traversal by product users.Page 236

12.1.2 用户交互设计

12.1.2 User Interaction Design

交互设计关注产品与其用户之间的界面。几年前,用户与计算机系统交互的唯一方式是在键盘上键入输入并在某种显示屏上读取输出。如今,输入和输出的模式多种多样,可能包括语音输入、计算机语音生成、触摸输入、3D 打印输出、沉浸式增强现实体验以及用户在其环境中的传感器跟踪。需要这样的设备来为用户提供控制计算机系统的方法。通常,这些交互设备会干扰产品提供自然且愉快的用户体验。

Interaction design focuses on the interface between a product and its user. Not too many years ago, the only way for a user to interact with a computer system was typing input on a keyboard and reading output on a display screen of some kind. Today the modes of input and output are quite varied and may include voice input, computer speech generation, touch input, 3D printed output, immersive augmented reality experiences, and sensor tracking of users within their environment. Devices like this are needed to give users ways to control a computer system. Oftentimes these interaction devices interfere with the product providing a natural and pleasurable user experience.

用户交互应该由利益相关者在用户故事(第 7 章)中定义,该用户故事创建用于描述用户如何使用软件产品实现其目标。这表明用户交互设计还应该包括如何在这样的系统中呈现信息以及如何使用户理解该信息的计划。重要的是要记住,用户界面的目的是提供足够的信息来帮助用户决定下一步应该采取什么行动来实现他们的目标以及如何执行它。

User interaction should be defined by the stakeholders in the user stories (Chapter 7) created to describe how users can accomplish their goals using the software product. This suggests that user interaction design should also include a plan for how information should be presented within such a system and how to enable the user to understand that information. It is important to recall that the purpose of the user interface is to present just enough information to help the users decide what their next action should be to accomplish their goal and how to perform it.

我们将在第 12.5 节中更详细地描述用户界面设计过程,但首先,用户交互设计师在设计用户界面时必须问一些重要的问题:1

We will describe the user interface design process in more detail in Section 12.5, but initially, there are important questions user interaction designers must ask when devising user interfaces:1

  • 用户可以用鼠标、手指或手写笔做什么来直接与界面交互?

  • What can users do with a mouse, finger, or stylus to interact with the interface directly?

  • 外观(例如颜色、形状、大小)如何为用户提供有关用户交互功能的线索?

  • What about the appearance (e.g., color, shape, size) gives users clues about how the user interaction functions?

  • 您提供哪些信息来让用户在执行操作之前知道会发生什么?

  • What information do you provide to let users know what will happen before they perform an action?

  • 是否有任何限制来帮助防止错误?

  • Are there any constraints put in place to help prevent errors?

  • 错误消息是否为用户提供了纠正问题或解释错误发生原因的方法?

  • Do error messages provide a way for users to correct a problem or explain why an error occurs?

  • 执行操作后,用户会得到什么反馈?

  • What feedback do users get once an action is performed?

  • 界面元素的大小是否合理以方便交互?

  • Are the interface elements a reasonable size to facilitate interaction?

  • 应使用哪些熟悉或标准的格式来显示信息和接受输入?

  • What familiar or standard formats should be used to display information and accept input?

12.1.3 可用性工程

12.1.3 Usability Engineering

可用性工程是用户体验设计工作的一部分,它定义软件产品的人机交互部分的规范、设计和测试。该软件工程行动的重点是设计具有高可用性的人机界面。可用性工程提供了实现界面设计高效和优雅的结构化方法。用户友好性等术语在这里并没有提供太多指导,因为这通常是一个非常主观的判断。如果开发人员专注于让产品随着时间的推移变得易于学习、易于使用和易于记住,则可以定量地衡量可用性并测试可用性的改进。

Usability engineering is part of UX design work that defines the specification, design, and testing of the human-computer interaction portion of a software product. This software engineering action focuses on devising human-computer interfaces that have high usability. Usability engineering provides structured methods for achieving efficiency and elegance in interface design. Terms like user friendliness do not provide much guidance here since this is often a very subjective judgment. If developers focus on making a product easy to learn, easy to use, and easy to remember over time, usability can be measured quantitatively and tested for improvements in usability.

第237页可访问性是可用性工程的另一个方面,在设计用户与软件的交互时应考虑这一点。可访问性是指为有特殊需要的人(例如视力障碍、耳聋、老年人、认知障碍)提供感知、理解、导航以及与计算机产品交互的手段的程度。可访问性设计的目标是提供硬件或软件工具,可以消除可能阻止用户成功完成软件支持的任务的障碍。可用性和可访问性在第 12.7 节中进行了更详细的讨论。

Page 237Accessibility is another aspect of usability engineering that should be considered when designing user interactions with the software. Accessibility is the degree to which people with special needs (e.g., sight impaired, deaf, elderly, cognitively impaired) are provided with a means to perceive, understand, navigate, and interact with computer products. The goal of accessibility design is to provide hardware or software tools that can remove barriers that may prevent users from successfully completing tasks supported by the software. Usability and accessibility are discussed in greater detail in Section 12.7.

12.1.4 视觉设计

12.1.4 Visual Design

视觉设计,也称为美学设计或图形设计,是一种补充用户体验设计技术方面的艺术努力。没有它,软件产品可能具有功能,但没有吸引力。有了它,产品就能将用户带入一个在内心和智力层面上拥抱他们的世界。

Visual design, also called aesthetic design or graphic design, is an artistic endeavor that complements the technical aspects of the user experience design. Without it, a software product may be functional, but unappealing. With it, a product draws its users into a world that embraces them on a visceral, as well as an intellectual level.

但什么是审美呢?有句老话说:“情人眼里出西施”。当考虑许多游戏或移动应用程序的美学设计时,这是特别合适的。为了执行有效的美学设计,您应该返回到作为需求模型一部分开发的用户层次结构(第 8 章),并询问“谁是产品的用户以及他们想要什么‘外观’?”

But what is aesthetic? There is an old saying, “Beauty exists in the eye of the beholder.” This is particularly appropriate when aesthetic design for many games or mobile apps is considered. To perform effective aesthetic design, you should return to the user hierarchy developed as part of the requirements model (Chapter 8) and ask, “Who are the product’s users and what ‘look’ do they desire?”

图形设计考虑网络或移动应用程序外观和感觉的各个方面。图形设计过程从屏幕布局开始,然后考虑全局配色方案;输入字体、大小和样式;使用辅助媒体(例如音频、视频、动画);以及应用程序的所有其他美学元素。并不是每个软件工程师都有艺术天赋。如果您属于此类,请聘请经验丰富的平面设计师进行美学设计工作。

Graphic design considers every aspect of the look and feel of a web or mobile app. The graphic design process begins with screen layout and proceeds into a consideration of global color schemes; type fonts, sizes, and styles; the use of supplementary media (e.g., audio, video, animation); and all other aesthetic elements of an application. Not every software engineer has artistic talent. If you fall into this category, hire an experienced graphic designer for aesthetic design work.

第238页

Page 238

12.2 黄金法则

12.2 The Golden Rules

Theo Mandel [Man97] 在他关于界面设计的书中提出了三个黄金法则:

In his book on interface design, Theo Mandel [Man97] coins three golden rules:

  1. 让用户处于控制之中。

  2. Place the user in control.

  3. 减少用户的内存负载。

  4. Reduce the user’s memory load.

  5. 使界面保持一致。

  6. Make the interface consistent.

这些黄金法则实际上构成了一组用户界面设计原则的基础,指导软件设计的这一重要方面。

These golden rules actually form the basis for a set of user interface design principles that guide this important aspect of software design.

12.2.1 让用户掌控

12.2.1 Place the User in Control

在一个主要的新信息系统的需求收集会议期间,一位关键用户被问及面向窗口的图形界面的属性。

During a requirements gathering session for a major new information system, a key user was asked about the attributes of the window-oriented graphical interface.

“我真正想要的是,”用户郑重地说,“是一个能读懂我想法的系统。它在我需要做之前就知道我想做什么,并且让我很容易完成它。仅此而已,仅此而已。”

“What I really would like,” said the user solemnly, “is a system that reads my mind. It knows what I want to do before I need to do it and makes it very easy for me to get it done. That’s all, just that.”

您的第一反应可能是摇头微笑,但暂停片刻。用户的要求完全没有问题。她想要一个能够满足她的需求并帮助她完成工作的系统。她想要控制电脑,而不是让电脑控制她。

Your first reaction might be to shake your head and smile, but pause for a moment. There was absolutely nothing wrong with the user’s request. She wanted a system that reacted to her needs and helped her get things done. She wanted to control the computer, not have the computer control her.

设计者施加的大多数界面约束和限制都是为了简化交互模式。但为了谁呢?

Most interface constraints and restrictions that are imposed by a designer are intended to simplify the mode of interaction. But for whom?

作为设计者,您可能会想引入约束和限制来简化界面的实现。结果可能是一个易于构建但使用起来令人沮丧的界面。Mandel [Man97] 定义了许多允许用户保持控制的设计原则:

As a designer, you may be tempted to introduce constraints and limitations to simplify the implementation of the interface. The result may be an interface that is easy to build, but frustrating to use. Mandel [Man97] defines a number of design principles that allow the user to maintain control:

  • 以不会强迫用户执行不必要或不期望的操作的方式定义交互模式。交互模式是界面的当前状态。例如,如果在短信应用程序菜单中选择自动更正,则该软件会持续执行自动更正。没有理由强迫用户保持自动更正模式。用户应该能够毫不费力地进入和退出该模式。

  • Define interaction modes in a way that does not force a user into unnecessary or undesired actions. An interaction mode is the current state of the interface. For example, if autocorrect is selected in a text messaging app menu, the software performs autocorrect continually. There is no reason to force the user to remain in autocorrect mode. The user should be able to enter and exit the mode with little or no effort.

  • 提供灵活的交互。由于不同的用户有不同的交互偏好,因此应该提供选择。例如,软件可能允许用户通过键盘命令、鼠标移动、数字笔、多点触摸屏或语音识别命令进行交互。但并不是每一个动作都适合每一种交互机制。例如,考虑使用键盘命令(或语音输入)绘制复杂形状的困难。

  • Provide for flexible interaction. Because different users have different interaction preferences, choices should be provided. For example, software might allow a user to interact via keyboard commands, mouse movement, a digitizer pen, a multitouch screen, or voice recognition commands. But every action is not amenable to every interaction mechanism. Consider, for example, the difficulty of using a keyboard command (or voice input) to draw a complex shape.

  • 允许用户交互可中断且不可撤销。即使涉及一系列操作,用户也应该能够中断该序列以执行其他操作(不会丢失已完成的工作)。用户还应该能够“撤消”任何操作或任何线性操作序列。

  • Allow user interaction to be interruptible and undoable. Even when involved in a sequence of actions, the user should be able to interrupt the sequence to do something else (without losing the work that had been done). The user should also be able to “undo” any action or any linear sequence of actions.

  • 第239页随着技能水平的提高,简化交互,并允许自定义交互。用户经常发现他们重复执行相同的交互序列。设计一种“宏”机制是值得的,该机制使高级用户能够自定义界面以方便交互。

  • Page 239Streamline interaction as skill levels advance, and allow the interaction to be customized. Users often find that they perform the same sequence of interactions repeatedly. It is worthwhile to design a “macro” mechanism that enables an advanced user to customize the interface to facilitate interaction.

  • 对普通用户隐藏技术内部细节。用户界面应该将用户带入应用程序的虚拟世界。用户不应该了解操作系统、文件管理功能或其他神秘的计算技术。

  • Hide technical internals from the casual user. The user interface should move the user into the virtual world of the application. The user should not be aware of the operating system, file management functions, or other arcane computing technology.

  • 设计用于与屏幕上出现的对象进行直接交互。当能够以类似于对象是物理事物时所发生的方式操作执行任务所需的对象时,用户会感受到控制感。例如,允许用户将文档拖入“垃圾箱”的应用程序界面就是直接操作的实现。

  • Design for direct interaction with objects that appear on the screen. The user feels a sense of control when able to manipulate the objects that are necessary to perform a task in a manner similar to what would occur if the object were a physical thing. For example, an application interface that allows a user to drag a document into the “trash” is an implementation of direct manipulation.

12.2.2 减少用户的内存负载

12.2.2 Reduce the User’s Memory Load

设计良好的用户界面不会消耗用户的记忆力,因为用户必须记住的越多,交互就越容易出错。只要有可能,系统就应该“记住”相关信息,并帮助用户进行有助于回忆的交互场景。Mandel [Man97] 定义了使界面能够减少用户内存负载的设计原则:

A well-designed user interface does not tax a user’s memory because the more a user has to remember, the more error-prone the interaction will be. Whenever possible, the system should “remember” pertinent information and assist the user with an interaction scenario that assists recall. Mandel [Man97] defines design principles that enable an interface to reduce the user’s memory load:

  • 减少对短期记忆的需求。当用户参与复杂的任务时,对短期记忆的需求可能会很大。界面的设计应减少记住过去的操作、输入和结果的要求。这可以通过提供视觉提示来实现,使用户能够识别过去的操作,而不必回忆它们。

  • Reduce demand on short-term memory. When users are involved in complex tasks, the demand on short-term memory can be significant. The interface should be designed to reduce the requirement to remember past actions, inputs, and results. This can be accomplished by providing visual cues that enable a user to recognize past actions, rather than having to recall them.

  • 建立有意义的默认值。初始默认设置对于普通用户应该有意义,但用户应该能够指定个人偏好。但是,应该提供“重置”选项,以便重新定义原始默认值。

  • Establish meaningful defaults. The initial set of defaults should make sense for the average user, but a user should be able to specify individual preferences. However, a “reset” option should be available, enabling the redefinition of original default values.

  • 定义直观的快捷方式。当助记符用于完成系统功能时(例如,ctrl-C 调用复制功能),助记符应以易于记忆的方式与操作相关联(例如,要调用的任务的第一个字母) 。

  • Define shortcuts that are intuitive. When mnemonics are used to accomplish a system function (e.g., ctrl-C to invoke the copy function), the mnemonic should be tied to the action in a way that is easy to remember (e.g., first letter of the task to be invoked).

  • 界面的视觉布局应该基于现实世界的隐喻。例如,账单支付系统应使用支票簿和支票登记器比喻来指导用户完成账单支付过程。房间布局应用程序应允许用户从视觉目录中拖动家具并使用触摸界面将其排列在屏幕上。这使得用户能够依赖易于理解的视觉提示,而不是记住晦涩难懂的交互序列。

  • The visual layout of the interface should be based on a real-world metaphor. For example, a bill payment system should use a checkbook and check register metaphor to guide the user through the bill paying process. A room layout application should allow users to drag furniture from a visual catalog and arrange it on the screen using a touch interface. This enables the user to rely on well-understood visual cues, rather than memorizing an arcane interaction sequence.

  • 第240页以渐进的方式披露信息。界面应该分层组织。也就是说,有关任务、对象或某些行为的信息应首先以高抽象级别呈现。在用户表示感兴趣后,应提供更多详细信息。

  • Page 240Disclose information in a progressive fashion. The interface should be organized hierarchically. That is, information about a task, an object, or some behavior should be presented first at a high level of abstraction. More detail should be presented after the user indicates interest.

12.2.3 使接口保持一致

12.2.3 Make the Interface Consistent

界面应该以一致的方式呈现和获取信息。这意味着(1)所有视觉信息都是根据在所有屏幕显示中维护的设计规则进行组织的,(2)输入机制仅限于在整个应用程序中一致使用的有限集,以及(3)从任务之间的定义和实施是一致的。Mandel [Man97] 定义了一组有助于使界面一致的设计原则:

The interface should present and acquire information in a consistent fashion. This implies that (1) all visual information is organized according to design rules that are maintained throughout all screen displays, (2) input mechanisms are constrained to a limited set that is used consistently throughout the application, and (3) mechanisms for navigating from task to task are consistently defined and implemented. Mandel [Man97] defines a set of design principles that help make the interface consistent:

  • 允许用户将当前任务放入有意义的上下文中。许多界面实现了与数十个屏幕图像的复杂交互层。提供使用户能够了解手头工作的上下文的指示符(例如,窗口标题、图形图标、一致的颜色编码)非常重要。此外,用户应该能够确定他来自哪里以及过渡到新任务有哪些替代方案。第241页

  • Allow the user to put the current task into a meaningful context. Many interfaces implement complex layers of interactions with dozens of screen images. It is important to provide indicators (e.g., window titles, graphical icons, consistent color coding) that enable the user to know the context of the work at hand. In addition, the user should be able to determine where he has come from and what alternatives exist for a transition to a new task.Page 241

  • 保持整个产品线的一致性。应用程序系列(即产品线)应实现相同的设计规则,以便保持所有交互的一致性。

  • Maintain consistency across a complete product line. A family of applications (i.e., a product line) should implement the same design rules so that consistency is maintained for all interaction.

  • 如果过去的交互模型已经创造了用户期望,则不要进行更改,除非有令人信服的理由这样做。一旦特定的交互序列成为事实上的标准(例如,使用 alt-S 来保存文件),用户就期望在遇到的每个应用程序中都这样做。更改(例如,使用 alt-S 调用缩放)将导致混乱。

  • If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so. Once a particular interactive sequence has become a de facto standard (e.g., the use of alt-S to save a file), the user expects this in every application encountered. A change (e.g., using alt-S to invoke scaling) will cause confusion.

本节和前面几节中讨论的界面设计原则为您提供基本指导。在接下来的部分中,您将了解用户体验设计过程本身。

The interface design principles discussed in this and the preceding sections provide you with basic guidance. In the sections that follow, you’ll learn about the user experience design process itself.

12.3 用户界面分析与设计

12.3 User Interface Analysis and Design

尽管用户体验设计工作不仅仅涉及用户界面,但用户界面设计是开始理解用户体验过程的一个好地方。分析和设计用户界面的整个过程始于创建不同的系统功能模型(从外部感知)。您首先描述实现系统功能所需的面向人和计算机的任务,然后考虑适用于所有界面设计的设计问题。使用工具进行原型设计并最终实现设计模型,最终用户对结果进行质量评估。

Although UX design work is not only about the user interface, design of the user interface is a good place to start understanding the UX process. The overall process for analyzing and designing a user interface begins with the creation of different models of system function (as perceived from the outside). You begin by delineating the human- and computer-oriented tasks that are required to achieve system function and then considering the design issues that apply to all interface designs. Tools are used to prototype and ultimately implement the design model, and the result is evaluated by end users for quality.

12.3.1 接口分析和设计模型

12.3.1 Interface Analysis and Design Models

当要分析和设计用户界面时,四种不同的模型将发挥作用。人类工程师(或软件工程师)建立用户模型,软件工程师创建设计模型,最终用户开发通常称为用户心理模型系统感知的心理图像,系统的实现者创建实施模型。不幸的是,这些模型中的每一个都可能存在显着差异。作为界面设计师,您的角色是协调这些差异并得出一致的界面表示。

Four different models come into play when a user interface is to be analyzed and designed. A human engineer (or the software engineer) establishes a user model, the software engineer creates a design model, the end user develops a mental image that is often called the user’s mental model or the system perception, and the implementers of the system create an implementation model. Unfortunately, each of these models may differ significantly. Your role, as an interface designer, is to reconcile these differences and derive a consistent representation of the interface.

用户模型建立了系统最终用户的概况。为了构建有效的用户界面,“所有设计都应该从了解目标用户开始,包括他们的年龄、性别、身体能力、教育、文化或种族背景、动机、目标和个性”[Shn16]。此外,用户还可以被归类为新手;知识渊博、间歇性的用户;或知识渊博的频繁用户。许多 UX 设计师喜欢构建用户配置文件或角色(第 12.4.2 节)作为捕获每类用户的已知信息的方式。

The user model establishes the profile of end users of the system. To build an effective user interface, “all design should begin with an understanding of the intended users, including profiles of their age, gender, physical abilities, education, cultural or ethnic background, motivation, goals and personality” [Shn16]. In addition, users can be categorized as novices; knowledgeable, intermittent users; or knowledgeable frequent users. Many UX designers like to build user profiles or personas (Section 12.4.2) as way of capturing what is known about each class of users.

用户心智模型(系统感知)是最终用户头脑中的系统形象。例如,如果对餐厅进行评级的移动应用程序的用户被要求描述其运营情况,系统感知将指导响应。描述的准确性将取决于用户的个人资料(例如,新手最多只能提供粗略的响应)以及对应用程序领域中的软件的总体熟悉程度。与花费数天尝试有效应用该应用程序的新手相比,完全了解餐厅评级应用程序但只使用过该特定应用程序几次的用户实际上可能能够提供更完整的功能描述。第242页

The user’s mental model (system perception) is the image of the system that end users carry in their heads. For example, if the user of a mobile app that rates restaurants were asked to describe its operation, the system perception would guide the response. The accuracy of the description will depend on the user’s profile (e.g., novices would provide a sketchy response at best) and overall familiarity with software in the application domain. A user who understands restaurant rating apps fully but has worked with the specific app only a few times might actually be able to provide a more complete description of its function than the novice who has spent days trying to apply the app effectively.Page 242

实现模型结合了基于计算机的系统的外在表现(界面的外观和感觉),以及描述界面语法和语义的所有支持信息(书籍、手册、录像带、帮助文件)。当实现模型与用户的心智模型一致时,用户通常会对软件感到满意并有效地使用它。为了实现模型的这种“融合”,设计模型必须能够容纳用户模型中包含的信息,并且实现模型必须准确地反映有关界面的语法和语义信息。

The implementation model combines the outward manifestation of the computer-based system (the look and feel of the interface), coupled with all supporting information (books, manuals, videotapes, help files) that describes interface syntax and semantics. When the implementation model and the user’s mental model are coincident, users generally feel comfortable with the software and use it effectively. To accomplish this “melding” of the models, the design model must have been developed to accommodate the information contained in the user model, and the implementation model must accurately reflect syntactic and semantic information about the interface.

12.3.2 过程

12.3.2 The Process

用户界面的分析和设计过程是迭代的,可以使用类似于第 4 章中讨论的过程模型来表示。参考图12.2,用户界面分析和设计过程从螺旋内部开始,包含四个不同的框架活动[Man97]:(1)界面分析和建模,(2)界面设计,(3)界面构建,以及(4)接口验证。图 12.2中所示的螺旋意味着这些任务中的每一个都将发生多次,围绕螺旋的每次传递都代表着对需求和最终设计的额外阐述。在大多数情况下,施工活动涉及原型设计——这是验证设计内容的唯一实用方法。

The analysis and design process for user interfaces is iterative and can be represented using a process model similar to the one discussed in Chapter 4. Referring to Figure 12.2, the user interface analysis and design process begins at the interior of the spiral and encompasses four distinct framework activities [Man97]: (1) interface analysis and modeling, (2) interface design, (3) interface construction, and (4) interface validation. The spiral shown in Figure 12.2 implies that each of these tasks will occur more than once, with each pass around the spiral representing additional elaboration of requirements and the resultant design. In most cases, the construction activity involves prototyping—the only practical way to validate what has been designed.

图12.2 用户界面设计流程

Figure 12.2 The user interface design process

第243页界面分析重点关注将与系统交互的用户的概况。记录技能水平、业务理解和对新系统的总体接受度;并定义了不同的用户类别。对于每个用户类别,都会引出需求。本质上,您致力于了解每类用户的系统感知(第 12.4.2 节)。

Page 243Interface analysis focuses on the profile of the users who will interact with the system. Skill level, business understanding, and general receptiveness to the new system are recorded; and different user categories are defined. For each user category, requirements are elicited. In essence, you work to understand the system perception (Section 12.4.2) for each class of users.

一旦定义了一般要求,就会进行更详细的任务分析。用户为实现系统目标而执行的那些任务被识别、描述和详细说明(通过螺旋的多次迭代)。任务分析在第 12.4.3 节中有更详细的讨论。最后,用户环境的分析重点关注物理工作环境的特征(例如位置、照明、位置限制)。

Once general requirements have been defined, a more detailed task analysis is conducted. Those tasks that the user performs to accomplish the goals of the system are identified, described, and elaborated (over a number of iterative passes through the spiral). Task analysis is discussed in more detail in Section 12.4.3. Finally, analysis of the user environment focuses on the characteristics of the physical work environment (e.g., location, lighting, position constraints).

作为分析操作的一部分收集的信息用于创建界面的分析模型。以此模型为基础,开始设计活动。

The information gathered as part of the analysis action is used to create an analysis model for the interface. Using this model as a basis, the design activity commences.

界面设计的目标是定义一组界面对象和操作(及其屏幕表示),使用户能够以满足为系统定义的每个可用性目标的方式执行所有定义的任务。接口设计在12.5 节中有更详细的讨论。

The goal of interface design is to define a set of interface objects and actions (and their screen representations) that enable a user to perform all defined tasks in a manner that meets every usability goal defined for the system. Interface design is discussed in more detail in Section 12.5.

界面构建通常从创建能够评估使用场景的原型开始。随着迭代设计过程的继续,可以使用用户界面工具包来完成界面的构造。

Interface construction normally begins with the creation of a prototype that enables usage scenarios to be evaluated. As the iterative design process continues, a user interface tool kit may be used to complete the construction of the interface.

接口验证侧重于(1)接口正确实现每个用户任务、适应所有任务变化以及实现所有一般用户需求的能力;(2) 界面易于使用和学习的程度,以及 (3) 用户接受界面作为工作中有用工具的程度。

Interface validation focuses on (1) the ability of the interface to implement every user task correctly, to accommodate all task variations, and to achieve all general user requirements; (2) the degree to which the interface is easy to use and easy to learn, and (3) the user’s acceptance of the interface as a useful tool in her work.

正如我们已经指出的,本节中描述的活动是迭代发生的。因此,无需在第一次就尝试指定每个细节(用于分析或设计模型)。随后通过该过程详细说明任务细节、设计信息和界面的操作功能。

As we have already noted, the activities described in this section occur iteratively. Therefore, there is no need to attempt to specify every detail (for the analysis or design model) on the first pass. Subsequent passes through the process elaborate task detail, design information, and the operational features of the interface.

12.4 用户体验分析2

12.4 User Experience Analysis2

所有软件工程过程模型的一个关键原则是:在尝试设计解决方案之前先了解问题。在用户体验设计的情况下,理解问题意味着理解(1)通过界面与系统交互的人(最终用户),(2)最终用户必须执行的工作任务,(3)作为界面一部分呈现的内容,以及 (4) 执行这些任务的环境。在接下来的部分中,我们将研究用户体验分析的每个元素,旨在为后续的界面设计任务奠定坚实的基础。第244页

A key tenet of all software engineering process models is this: Understand the problem before you attempt to design a solution. In the case of user experience design, understanding the problem means understanding (1) the people (end users) who will interact with the system through the interface, (2) the tasks that end users must perform to do their work, (3) the content that is presented as part of the interface, and (4) the environment in which these tasks will be conducted. In the sections that follow, we examine each of these elements of UX analysis with the intent of establishing a solid foundation for the interface design tasks that follow.Page 244

12.4.1 用户研究

12.4.1 User Research

用户界面这个短语可能是在担心技术问题之前花一些时间了解用户所需的全部理由。之前我们注意到,每个用户对软件的心理印象可能与其他用户形成的心理形象不同。此外,用户的心理形象可能与软件工程师的设计模型有很大不同。使心理形象和设计模型融合的唯一方法是努力了解用户本身以及这些人将如何使用系统。来自广泛来源的信息(用户访谈、销售输入、营销输入、支持输入)可用于实现这一目标。

The phrase user interface is probably all the justification needed to spend some time understanding the user before worrying about technical matters. Earlier we noted that each user has a mental image of the software that may be different from the mental image developed by other users. In addition, the user’s mental image may be vastly different from the software engineer’s design model. The only way that you can get the mental image and the design model to converge is to work to understand the users themselves as well as how these people will use the system. Information from a broad array of sources (user interviews, sales input, marketing input, support input) can be used to accomplish this.

许多用户体验开发人员喜欢创建客户旅程地图图 12.3)作为概述他们的软件产品目标和计划的方法。客户旅程地图显示了用户将如何体验软件产品,就好像他们正在进行一次实际旅行一样,其中包含接触点(里程碑)、障碍以及监控进度的方法。Christensen [Chr13] 建议按照以下步骤创建客户旅程地图:

Many UX developers like to create a customer journey map (Figure 12.3) as a means of outlining their goals and plans for the software product. The customer journey map shows how the users will experience the software product as if they were traveling on a physical trip with touchpoints (milestones), obstacles, and ways to monitor their progress. Christensen [Chr13] suggests the following steps to create a customer journey map:

12.3客户 旅程图

Figure 12.3 Customer journey map

  1. 聚集利益相关者。找到所有需要的受影响方,以确保客户旅程地图中包含不同的观点。

  2. Gather stakeholders. Locate all affected parties needed to ensure diverse viewpoints are included in the customer journey map.

  3. 进行研究。收集用户在使用软件产品时可能遇到的所有事物(想法、感受、行动、动机、期望、目标、需求、痛点、障碍、问题)的所有信息,并定义您的客户阶段。客户阶段将成为您的接触点,并如图 12.3中的标记方块所示。第245页

  4. Conduct research. Collect all information you can about all the things (thoughts, feelings, actions, motivations, expectations, goals, needs, pain points, barriers, questions) users may experience as they use the software product and define your customer phases. The customer phases will become your touchpoints and are shown as labeled squares in Figure 12.3.Page 245

  5. 构建模型。创建接触点(用户和产品之间的任何交互)、渠道(交互设备或信息流)以及客户(用户)采取的操作的可视化。

  6. Build the model. Create a visualization of the touch points (any interaction between the user and product), channels (interaction devices or information streams), and actions taken by the customer (user).

  7. 完善设计。聘请设计师,使交付成果具有视觉吸引力,并确保清楚地识别客户阶段。

  8. Refine the design. Recruit a designer to make the deliverable visually appealing and ensure that customer phases are identified clearly.

  9. 找出差距。注意客户体验中的任何差距或摩擦点或痛苦点(信息重叠或阶段之间过渡不良的地方)。

  10. Identify gaps. Note any gaps in the customer experience or points of friction or pain (places with information overlap or poor transition between phases).

  11. 实施你的发现。指定责任方来弥合差距并解决发现的痛点。

  12. Implement your findings. Assign responsible parties to bridge the gaps and resolve pain points found.

12.4.2 用户建模

12.4.2 User Modeling

在前面的章节中,您了解到用户故事描述了参与者(在用户界面设计的上下文中,参与者始终是人)与系统交互的方式。当用作任务分析的一部分时,用户故事被细化为正式用例,以显示最终用户如何执行某些特定的与工作相关的任务。在大多数情况下,用例是以第一人称的非正式风格(简单的段落)编写的。例如,假设一家小型软件公司想要专门为室内设计师构建计算机辅助设计系统。为了更好地了解他们的工作方式,实际的室内设计师被要求描述特定的设计功能。当被问到“你如何决定在房间里放置家具的位置?” 一位室内设计师写了以下非正式的用户故事:

In previous chapters, you learned that the user story describes the manner in which an actor (in the context of user interface design, an actor is always a person) interacts with a system. When used as part of task analysis, the user story is refined to become a formal use case to show how an end user performs some specific work-related task. In most instances, the use case is written in an informal style (a simple paragraph) in the first person. For example, assume that a small software company wants to build a computer-aided design system explicitly for interior designers. To get a better understanding of how they do their work, actual interior designers are asked to describe a specific design function. When asked, “How do you decide where to put furniture in a room?” an interior designer writes the following informal user story:

我首先绘制房间的平面图、门窗的尺寸和位置。我非常关心进入房间的光线、窗外的景色(如果它很漂亮,我想引起人们的注意)、畅通无阻的墙壁的长度、穿过房间的运动流程。房间。然后我查看我和客户选择的家具清单。。。。然后,我绘制房间的渲染图(3D 图片),让客户感受房间的外观。

I begin by sketching the floor plan of the room, the dimensions and the location of windows and doors. I’m very concerned about light as it enters the room, about the view out of the windows (if it’s beautiful, I want to draw attention to it), about the running length of an unobstructed wall, about the flow of movement through the room. I then look at the list of furniture my customer and I have chosen. . . . Then, I draw a rendering (a 3-D picture) of the room to give my customer a feel for what it’ll look like.

该用户故事从一位用户的角度提供了计算机辅助设计系统一项重要工作任务的基本描述。您可以从中提取任务、对象和交互的整体流程。此外,还可以设想系统的其他令室内设计师满意的功能。例如,可以拍摄一张从房间的每个窗户往外看的数码照片。当渲染房间时,可以通过每个窗口呈现实际的外部视图。但是,如果存在不止一种类型的用户,则为用户故事描述的系统定义多于一组的用户目标可能很重要。

This user story provides a basic description of one important work task for the computer-aided design system from the perspective of one of its users. From it, you can extract tasks, objects, and the overall flow of the interaction. In addition, other features of the system that would please the interior designer might also be conceived. For example, a digital photo could be taken looking out each window in a room. When the room is rendered, the actual outside view could be represented through each window. However, if there is more than one type of user, it may be important to define more than one set of user goals for the system described by the user stories.

用户体验设计师经常创建虚构的用户角色来总结针对不同类型用户所做的假设。用户角色是假设的用户组的目标和行为的表示。角色通常是根据用户访谈期间收集的数据合成的。图 12.4显示了用户角色的示例。人物角色通常用于提高产品设计师从目标用户的角度看待问题的能力 [Hil17]。第246页

User experience designers often create fictional user personas to summarize the assumptions made for the different types of users. A user persona is a representation of the goals and behavior of a hypothesized group of users. Personas are often synthesized from data collected during interviews with users. Figure 12.4 shows an example of a user persona. Personas are often used to improve product designers’ abilities to see through the eyes of target users [Hil17].Page 246

图12.4角色 示例

Figure 12.4 Persona example

Lene Nielsen [Nie13] 描述了创建和使用角色来指导用户体验设计过程的一般过程中发生的四项任务:

Lene Nielsen [Nie13] describes four tasks that occur during the general process of creating and using personas to guide the user experience design process:

  • 数据收集和分析。利益相关者收集尽可能多的有关拟议产品用户的信息,以确定用户组并开始强调每个组的需求。

  • Data collection and analysis. Stakeholders collect as much information about the proposed product users as possible to determine the user groups and begin to emphasize what each group needs.

  • 描述人物角色。开发人员需要决定创建多少个角色是合理的,是否要创建多个角色,以及哪个角色将是他们的主要关注点。开发人员创建并命名每个角色,包括有关他们的教育、生活方式、价值观、目标、需求、限制、欲望、态度和行为模式的详细信息。

  • Describe personas. The developers need to decide how many personas it is reasonable to create, if they will create more than one, and which persona will be their primary focus. The developers create and name each persona including details about their education, lifestyle, values, goals, needs, limitations, desires, attitudes, and behavior patterns.

  • 开发场景。场景是关于角色将如何使用正在开发的产品的用户故事。他们可能会关注客户旅程中描述的接触点和障碍。他们应该展示如果角色是系统的实际用户,他们将如何使用系统资源克服问题。

  • Develop scenarios. Scenarios are user stories about how personas will use the product being developed. They may focus on the touchpoints and obstacles described in the customer journey. They should show how personas would overcome problems using the system resources if they were the actual users of the system.

  • 利益相关者的接受。通常,这是通过使用称为认知演练的审查技术或演示来验证场景来完成的。3利益相关者承担角色定义的角色,并使用系统原型完成场景。第247页

  • Acceptance by stakeholders. Often this is done by validating the scenarios using a review technique or demonstration called cognitive walkthrough.3 Stakeholders assume the role defined by the persona and work through a scenario using a system prototype.Page 247

12.4.3 任务分析

12.4.3 Task Analysis

用户的目标是通过软件产品完成一项或多项任务。为了实现这一目标,软件用户界面必须提供允许用户实现其目标的机制。任务或场景分析的目标是回答以下问题:

The user’s goal is to accomplish one or more tasks via the software product. To accomplish this, the software user interface must provide mechanisms that allow the user to achieve her goal. The goal of task or scenario analysis is to answer the following questions:

  • 用户在特定情况下会执行什么工作?

  • What work will the user perform in specific circumstances?

  • 当用户工作时将执行哪些任务和子任务?

  • What tasks and subtasks will be performed as the user does the work?

  • 第248页当工作执行时,用户将操作哪些特定的问题域对象?

  • Page 248What specific problem domain objects will the user manipulate as work is performed?

  • 工作任务的顺序(工作流程)是什么?

  • What is the sequence of work tasks—the workflow?

  • 任务的层次结构是怎样的?

  • What is the hierarchy of tasks?

要回答这些问题,您必须利用我们在本书前面讨论过的技术,但在本例中,这些技术应用于用户界面。

To answer these questions, you must draw upon techniques that we have discussed earlier in this book, but in this instance, these techniques are applied to the user interface.

第 8 章中,我们讨论了逐步细化(也称为功能分解或逐步细化)作为细化软件完成某些所需功能所需的处理任务的机制。界面设计的任务分析使用精细的方法来帮助理解用户界面必须适应的人类活动。

In Chapter 8, we discussed stepwise elaboration (also called functional decomposition or stepwise refinement) as a mechanism for refining the processing tasks that are required for software to accomplish some desired function. Task analysis for interface design uses an elaborative approach that assists in understanding the human activities the user interface must accommodate.

首先,您应该定义并分类完成系统或应用程序目标所需的人工任务。例如,让我们重新考虑一下前面讨论的室内设计师的计算机辅助设计系统。通过观察室内设计师的工作,您会发现室内设计包括许多主要活动:家具布局(注意前面讨论的用户故事)、织物和材料选择、墙壁和窗户覆盖物选择、演示(向客户)、成本核算和购物。这些主要任务中的每一个都可以细化为子任务。例如,使用用例中包含的信息,家具布局可以细化为以下任务:(1) 根据房间尺寸绘制平面图,(2) 将门窗放置在适当的位置,(3a) 使用家具模板在平面图上绘制按比例缩放的家具轮廓,(3b) 使用强调模板在平面图上绘制按比例强调的强调轮廓,(4) 移动家具轮廓和强调轮廓以获得最佳位置,(5) 标记所有家具和强调轮廓, (6) 绘制尺寸以显示位置,以及 (7) 为客户绘制透视图。类似的方法可用于其他每项主要任务。

First, you should define and classify the human tasks that are required to accomplish the goal of the system or app. For example, let’s reconsider the computer-aided design system for interior designers discussed earlier. By observing an interior designer at work, you notice that interior design comprises a number of major activities: furniture layout (note the user story discussed earlier), fabric and material selection, wall and window coverings selection, presentation (to the customer), costing, and shopping. Each of these major tasks can be elaborated into subtasks. For example, using information contained in the use case, furniture layout can be refined into the following tasks: (1) draw a floor plan based on room dimensions, (2) place windows and doors at appropriate locations, (3a) use furniture templates to draw scaled furniture outlines on the floor plan, (3b) use accents templates to draw scaled accents on the floor plan, (4) move furniture outlines and accent outlines to get the best placement, (5) label all furniture and accent outlines, (6) draw dimensions to show location, and (7) draw a perspective-rendering view for the customer. A similar approach could be used for each of the other major tasks.

子任务 1 至 7 均可以进一步细化。子任务 1 至 6 将通过在用户界面内操纵信息和执行操作来执行。另一方面,子任务 7 可以在软件中自动执行,并且几乎不需要直接的用户交互。4界面的设计模型应以与用户模型(“典型”室内设计师的概况)和系统感知(室内设计师对自动化系统的期望)一致的方式适应每项任务。

Subtasks 1 to 7 can each be refined further. Subtasks 1 to 6 will be performed by manipulating information and performing actions within the user interface. On the other hand, subtask 7 can be performed automatically in software and will result in little direct user interaction.4 The design model of the interface should accommodate each of these tasks in a way that is consistent with the user model (the profile of a “typical” interior designer) and system perception (what the interior designer expects from an automated system).

12.4.4工作环境分析

12.4.4 Work Environment Analysis

Hackos 和 Redish [Hac98] 是这样讨论工作环境分析的:“人们并不是孤立地执行工作的。他们受到周围活动、工作场所的物理特征、所使用的设备类型以及与其他人的工作关系的影响。” 在某些应用中,基于计算机的系统的用户界面被放置在“用户友好的位置”(例如,适当的照明、良好的显示高度、方便的键盘访问),但在其他应用中(例如,工厂车间或飞机驾驶舱) ),照明可能不是最佳的,噪音可能是一个因素,键盘、鼠标或触摸屏可能不是一个选择,或者显示器的放置可能不太理想。界面设计者可能会受到影响易用性的因素的限制。第249页

Hackos and Redish [Hac98] discuss work environment analysis this way: “People do not perform their work in isolation. They are influenced by the activity around them, the physical characteristics of the workplace, the type of equipment they are using, and the work relationships they have with other people.” In some applications the user interface for a computer-based system is placed in a “user-friendly location” (e.g., proper lighting, good display height, easy keyboard access), but in others (e.g., a factory floor or an airplane cockpit), lighting may be suboptimal, noise may be a factor, a keyboard or mouse or touch screen may not be an option, or display placement may be less than ideal. The interface designer may be constrained by factors that mitigate against ease of use.Page 249

除了自然环境因素外,工作场所文化也发挥着作用。系统交互是否会以某种方式进行衡量(例如,每笔交易的时间或交易的准确性)?是否需要两个或更多人共享信息才能提供意见?如何向系统用户提供支持?这些以及许多相关问题应该在界面设计开始之前得到回答。

In addition to physical environmental factors, the workplace culture also comes into play. Will system interaction be measured in some manner (e.g., time per transaction or accuracy of a transaction)? Will two or more people have to share information before an input can be provided? How will support be provided to users of the system? These and many related questions should be answered before the interface design commences.

12.5 用户体验设计

12.5 User Experience Design

与所有迭代过程一样,分析和设计之间没有明确的划分。图12.5说明了用户研究和设计之间循环的实践,以及设计和施工之间循环的实践。重点是创建增量原型并通过实际用户进行测试。

As with all iterative processes, there is not a clean division between analysis and design. Figure 12.5 illustrates the practice of cycling between user research and design, as well as cycling between design and construction. The emphasis is on creating incremental prototypes and by testing it with actual users.

图12.5迭代 UX 设计流程

Figure 12.5 Iterative UX design process

Google 定义了 5 天的 UX 设计冲刺 [Kna16]、[Goo18]、[DXL18]。这些步骤概述如下,每个步骤分配一天:

Google has defined a 5-day sprint for doing UX design [Kna16], [Goo18], [DXL18]. The steps are outlined below with one day allocated to each:

  • 理解。包括用户研究活动,团队在其中收集有关软件产品要解决的问题(用户需求和业务目标)的信息;实现这一目标的一种方法是由领域专家就业务案例、竞争产品和用户概况等主题进行一系列闪电演讲(10 到 15 分钟的演示)。该信息在白板上捕获(例如,作为客户旅程地图、人物角色或用户任务工作流程),并在整个冲刺过程中保持发布以便于参考。第 250 页

  • Understand. Encompasses the user research activities in which the team gathers the information on the problem to be solved (user needs and business goals) for the software product; one way of doing this is to have a series of lightning talks (10- to 15-minute presentations) by domain experts on topics such as the business case, competing products, and user profiles. This information is captured on whiteboards (e.g., as customer journey maps, personas, or user task workflow) and remains posted for easy reference throughout the sprint.Page 250

  • 草图。各个团队成员(包括所有利益相关者)都有所需的时间和空间,针对理解阶段发现的问题集思广益解决方案。最好将其作为快速视觉图像在纸上进行。纸质图纸和笔记很容易生成、修改,而且相当便宜。此阶段会产生大量想法,因为参与者的想法在创建解决方案时不受限制。

  • Sketch. Individual team members (including all stakeholders) are given the time and space needed to brainstorm solutions to the problems discovered in the understand phase. It is best to do this on paper as quick visual images. Paper drawings and notes are easy to generate, easy to modify, and quite inexpensive. This phase generates lots of ideas because participant ideas are not restricted when creating their solutions.

  • 决定。每个利益相关者都会提出他的解决方案草图,团队投票决定在接下来的原型设计活动中应解决的解决方案。如果投票后没有达成明确的共识,开发团队可能会决定考虑涉及预算、用户概况、可用资源(人力和技术)和产品业务目标所带来的约束的假设。

  • Decide. Each stakeholder presents his solution sketch, and the team votes to determine the solutions that should be tackled in the prototyping activities that will follow. If there is not a clear consensus following the voting, the development team may decide to consider assumptions that involve constraints posed by the budget, user profiles, available resources (both human and technological), and product business goals.

  • 原型。在此阶段创建的原型可能是基于从草图阶段选择的解决方案的最低限度可行的产品,也可能基于您希望在验证阶段与潜在用户一起评估的客户旅程地图或故事板的部分。将您的原型视为为检验假设而开发的实验。这意味着团队应该在构建原型时根据用户故事开发测试用例。无需为此用户界面原型创建功能齐全的后端。最好使用简单的工具(例如 Keynote 5)构建数字原型。在某些情况下,如果没有可用的原型设计工具,可能需要使用开发人员之一来创建纸质原型,以向用户提供屏幕序列。

  • Prototype. The prototype created during this phase may be a minimally viable product based on the solution selected from the sketch phase, or it may be based on the portions of the customer journey map or storyboard you want to evaluate with potential users in the validate phase. Think of your prototype as an experiment developed to test a hypothesis. That means the team should be developing test cases based on the user stories as the prototype is being built. There is no need to create a fully functional backend for this user interface prototype. It would be best to build a digital prototype using a simple tool (e.g., Keynote5). In some cases it may be desirable to create a paper prototype using one of the developers to provide the screen sequences to the users if a prototyping tool is not available.

  • 证实。观看用户试用您的原型是发现用户体验设计主要问题的最佳方式,这反过来又可以让您立即开始迭代。在用户体验设计冲刺中,开发团队中的每个人都会观察验证会话,而不仅仅是用户体验专家或测试用例设计者。这对于通过让产品决策者实时了解用户反馈来捕捉潜在的学习机会至关重要。我们将在12.7 节中详细讨论原型审查和用户测试。

  • Validate. Watching users try out your prototype is the best way to discover major issues with its UX design, which in turn lets you start iterating immediately. In a UX design sprint everyone on the development team observes the validation sessions, not just the UX expert or test case designer. This is critical to capturing potential learning opportunities by exposing product decision makers to user feedback in real time. We will talk more about prototype reviews and user testing in Section 12.7.

12.6 用户界面设计

12.6 User Interface Design

界面对象的定义以及应用于它们的操作是界面设计中的重要步骤。为了实现这一点,用户场景的解析方式与第 9 章中描述的方式大致相同。也就是说,编写了一个用例。名词(对象)和动词(动作)被隔离以创建屏幕对象和系统动作的列表。

The definition of interface objects and the actions that are applied to them is an important step in interface design. To accomplish this, user scenarios are parsed in much the same way as described in Chapter 9. That is, a use case is written. Nouns (objects) and verbs (actions) are isolated to create a list of screen objects and systems actions.

第251页一旦对象和动作被迭代地定义和详细阐述,它们就按类型进行分类。识别目标、源和应用程序对象。将源对象(例如,传感器图标)拖放到目标对象(例如,屏幕位置)上。此操作的含义是在房间平面图上放置一个传感器。应用程序对象表示特定于应用程序的数据,这些数据不作为屏幕交互的一部分直接操作。例如,用于模拟房间传感器覆盖范围的代码允许测试传感器的放置。当对象放置在屏幕上时,代码将通过某种类型的逻辑链接与每个传感器关联,但代码本身不会通过用户交互进行拖放。

Page 251Once the objects and actions have been defined and elaborated iteratively, they are categorized by type. Target, source, and application objects are identified. A source object (e.g., a sensor icon) is dragged and dropped onto a target object (e.g., a screen location). The implication of this action is to place a sensor on the room floor plan. An application object represents application-specific data that are not directly manipulated as part of screen interaction. For example, the code used to simulate the coverage of the room sensors allow for testing of the sensor placement. The code would be associated with each sensor through some type of logical link when the object is placed on the screen, but the code itself is not dragged and dropped via user interaction.

当您对已定义的所有重要对象和操作(针对一次设计迭代)感到满意时,将执行屏幕布局。与其他界面设计活动一样,屏幕布局是一个交互过程,其中进行图形设计和图标放置、描述性屏幕文本的定义、窗口的规范和标题以及主要和次要菜单项的定义。如果现实世界的隐喻适合应用程序,则此时指定它,并且以补充隐喻的方式组织布局。

When you are satisfied that all important objects and actions have been defined (for one design iteration), screen layout is performed. Like other interface design activities, screen layout is an interactive process in which graphical design and placement of icons, definition of descriptive screen text, specification and titling for windows, and definition of major and minor menu items are conducted. If a real-world metaphor is appropriate for the application, it is specified at this time, and the layout is organized in a manner that complements the metaphor.

12.6.1 应用界面设计步骤

12.6.1 Applying Interface Design Steps

为了简要说明如何进行设计以创建用户界面原型,让我们考虑SafeHome系统的用户场景(在前面的章节中讨论过)。该界面的初步用户故事(由房主编写)如下:

To provide a brief illustration of how design might proceed to create a prototype of a user interface, let’s consider a user scenario for the SafeHome system (discussed in earlier chapters). A preliminary user story (written by the homeowner) for the interface follows:

  • 初步用户故事:我想通过互联网从任何远程位置访问我的SafeHome系统。使用移动设备上运行的浏览器软件(当我在工作或旅行时),我可以确定警报系统的状态、布防或撤防系统、重新配置安全区域以及通过预装的摄像机查看房屋内的不同房间。

  • Preliminary user story: I want to gain access to my SafeHome system from any remote location via the Internet. Using browser software operating on my mobile device (while I’m at work or traveling), I can determine the status of the alarm system, arm or disarm the system, reconfigure security zones, and view different rooms within the house via preinstalled video cameras.

  • 为了从远程位置访问SafeHome,我提供了标识符和密码。这些定义了访问级别(例如,所有用户可能无法重新配置系统)并提供安全性。验证后,我可以检查系统的状态并通过布防或撤防SafeHome 来更改状态。我可以通过显示房屋的平面图、查看每个安全传感器、显示每个当前配置的区域以及根据需要修改区域来重新配置系统。我可以通过精心放置的摄像机查看房子的内部。我可以平移和缩放每个摄像机以提供不同的内部视图。

  • To access SafeHome from a remote location, I provide an identifier and a password. These define levels of access (e.g., all users may not be able to reconfigure the system) and provide security. Once validated, I can check the status of the system and change the status by arming or disarming SafeHome. I can reconfigure the system by displaying a floor plan of the house, viewing each of the security sensors, displaying each currently configured zone, and modifying zones as required. I can view the interior of the house via strategically placed video cameras. I can pan and zoom each camera to provide different views of the interior.

根据此用户故事,确定了以下房主任务、对象和数据项:

Based on this user story, the following homeowner tasks, objects, and data items are identified:

  • 访问SafeHome系统_

  • Accesses the SafeHome system

  • 输入ID和密码以允许远程访问

  • Enters an ID and password to allow remote access

  • 检查 系统状态

  • Checks system status

  • 布防撤防 SafeHome系统

  • Arms or disarms SafeHome system

  • 显示 平面图传感器位置

  • Displays floor plan and sensor locations

  • 在平面图上显示区域

  • Displays zones on floor plan

  • 更改 平面图上的区域

  • Changes zones on floor plan

  • 在平面图上显示摄像机位置

  • Displays video camera locations on floor plan

  • 第252页选择 用于观看的摄像机

  • Page 252Selects video camera for viewing

  • 查看 视频图像(每秒四帧)

  • Views video images (four frames per second)

  • 平移缩放摄像机_

  • Pans or zooms the video camera

对象(粗体)和操作(斜体)是从房主任务列表中提取的。所提到的大多数对象都是应用程序对象。然而,摄像机位置(源对象)被拖放到摄像机(目标对象)上以创建视频图像(具有视频显示的窗口)。

Objects (boldface) and actions (italics) are extracted from this list of homeowner tasks. The majority of objects noted are application objects. However, video camera location (a source object) is dragged and dropped onto video camera (a target object) to create a video image (a window with video display).

创建视频监控屏幕布局的初步草图(图 12.6)。6要调用视频图像,请选择监控窗口中显示的平面图中的摄像机位置图标C。在这种情况下,将客厅 (LR) 中的摄像机位置拖放到屏幕左上角的摄像机图标上。出现视频图像窗口,显示来自 LR 中摄像机的流视频。缩放和平移控制滑块用于控制视频图像的放大倍数和方向。要从另一个摄像机选择视图,用户只需将不同的摄像机位置图标拖放到屏幕左上角的摄像机图标中即可。

A preliminary sketch of the screen layout for video monitoring is created (Figure 12.6).6 To invoke the video image, a video camera location icon, C, located in the floor plan displayed in the monitoring window is selected. In this case a camera location in the living room (LR) is then dragged and dropped onto the video camera icon in the upper-left-hand portion of the screen. The video image window appears, displaying streaming video from the camera located in the LR. The zoom and pan control slides are used to control the magnification and direction of the video image. To select a view from another camera, the user simply drags and drops a different camera location icon into the camera icon in the upper-left-hand corner of the screen.

图12.6初步 屏幕布局

Figure 12.6 Preliminary screen layout

所显示的布局草图必须通过菜单栏中每个菜单项的扩展来补充,指示哪些操作可用于视频监控模式(状态)。在界面设计期间,将针对用户场景中记录的每个房主任务创建一套完整的草图。

The layout sketch shown would have to be supplemented with an expansion of each menu item within the menu bar, indicating what actions are available for the video monitoring mode (state). A complete set of sketches for each homeowner task noted in the user scenario would be created during the interface design.

12.6.2 用户界面设计模式

12.6.2 User Interface Design Patterns

图形用户界面已经变得如此普遍,以至于出现了各种各样的用户界面设计模式。设计模式是一种抽象,它规定了特定的、有边界的设计问题的设计解决方案。

Graphical user interfaces have become so common that a wide variety of user interface design patterns has emerged. A design pattern is an abstraction that prescribes a design solution to a specific, well-bounded design problem.

第253页作为一个常见的界面设计问题的示例,请考虑这样一种情况:用户必须输入一个或多个日历日期,有时是提前几个月。对于这个简单的问题有许多可能的解决方案,并且可能会提出许多不同的模式。Laakso [Laa00] 建议使用一种称为CalendarStrip的模式,该模式会生成一个连续的、可滚动的日历,其中突出显示当前日期,并且可以通过从日历中选取未来的日期来选择它们。日历隐喻为每个用户所熟知,并提供了一种在上下文中放置未来日期的有效机制。

Page 253As an example of a commonly encountered interface design problem, consider a situation in which a user must enter one or more calendar dates, sometimes months in advance. There are many possible solutions to this simple problem, and a number of different patterns that might be proposed. Laakso [Laa00] suggests a pattern called CalendarStrip that produces a continuous, scrollable calendar in which the current date is highlighted and future dates may be selected by picking them from the calendar. The calendar metaphor is well known to every user and provides an effective mechanism for placing a future date in context.

在过去的几十年里,人们提出了大量的界面设计模式。7第 14 章对用户界面设计模式进行了更详细的讨论。此外,Punchoojit [Pun17] 提供了对许多移动设备用户界面设计模式(例如,缩放、横向访问、在上下文中显示信息、控制和构造)的系统回顾。

A vast array of interface design patterns has been proposed over the past few decades.7 A more detailed discussion of user interface design patterns is presented in Chapter 14. In addition, Punchoojit [Pun17] provides a systematic review of many mobile device user interface design patterns (e.g., zooming, lateral access, revealing information in context, control, and conformation).

12.7 设计评估

12.7 Design Evaluation

一旦创建了可操作的用户界面原型,就必须对其进行评估以确定它是否满足用户的需求。评估可以涵盖从非正式的“试驾”(用户提供即兴反馈)到正式设计的研究(使用统计方法评估最终用户群体完成的调查问卷)等一系列形式。

Once you create an operational user interface prototype, it must be evaluated to determine whether it meets the needs of the user. Evaluation can span a formality spectrum that ranges from an informal “test drive,” in which a user provides impromptu feedback to a formally designed study that uses statistical methods for the evaluation of questionnaires completed by a population of end users.

用户界面评估周期采用如图 12.7所示的形式。设计模型完成后,将创建第一级原型。原型由用户评估,8他为您提供有关界面功效的直接评论。此外,如果使用正式的评估技术(例如,调查问卷、评级表),您可以从这些数据中提取信息(例如,80% 的用户不喜欢保存数据文件的机制)。根据用户输入进行设计修改,并创建下一个级别的原型。评估周期将持续到不需要对界面设计进行进一步修改为止。我们将在第 21 章中讨论图形用户界面的专门原型审查和测试技术。

The user interface evaluation cycle takes the form shown in Figure 12.7. After the design model has been completed, a first-level prototype is created. The prototype is evaluated by the user,8 who provides you with direct comments about the efficacy of the interface. In addition, if formal evaluation techniques are used (e.g., questionnaires, rating sheets), you can extract information from these data (e.g., 80 percent of all users did not like the mechanism for saving data files). Design modifications are made based on user input, and the next level prototype is created. The evaluation cycle continues until no further modifications to the interface design are necessary. We discuss specialized prototype review and testing techniques for graphical user interfaces in Chapter 21.

12.7 界面设计评估周期

Figure 12.7 The interface design evaluation cycle

12.7.1 原型审查

12.7.1 Prototype Review

第254页原型设计方法是有效的,但是是否可以在构建原型之前评估用户界面的质量?9如果尽早发现并纠正潜在问题,评估周期的循环次数将会减少,开发时间也会缩短。如果已经创建了界面的设计模型(用户故事、故事板、人物角色等),则可以在早期设计审查期间应用许多评估标准[Mor81]:

Page 254The prototyping approach is effective, but is it possible to evaluate the quality of a user interface before a prototype is built?9 If you identify and correct potential problems early, the number of loops through the evaluation cycle will be reduced and development time will shorten. If a design model (user stories, storyboard, personas, etc.) of the interface has been created, a number of evaluation criteria [Mor81] can be applied during early design reviews:

  1. 系统及其接口的需求模型或书面规范的长度和复杂性表明了系统用户所需的学习量。

  2. The length and complexity of the requirements model or written specification of the system and its interface provide an indication of the amount of learning required by users of the system.

  3. 指定的用户任务数和每个任务的平均操作数提供了交互时间和系统整体效率的指示。

  4. The number of user tasks specified and the average number of actions per task provide an indication of interaction time and the overall efficiency of the system.

  5. 设计模型指示的操作、任务和系统状态的数量意味着系统用户的内存负载。

  6. The number of actions, tasks, and system states indicated by the design model imply the memory load on users of the system.

  7. 界面风格、帮助设施和错误处理协议提供了界面复杂性和用户接受程度的一般指示。

  8. Interface style, help facilities, and error-handling protocol provide a general indication of the complexity of the interface and the degree to which it will be accepted by the user.

12.7.2 用户测试

12.7.2 User Testing

一旦构建了第一个交互式原型,您就可以收集各种定性和定量数据,以帮助评估界面。为了收集定性数据,可以分发允许用户评估界面原型的调查问卷。如果需要定量数据,可以进行某种形式的时间研究分析。在交互过程中观察用户和数据——例如在标准时间段内正确完成的任务数量、操作频率、操作顺序、“查看”显示屏所花费的时间、错误的数量和类型、错误恢复时间、时间收集使用帮助所花费的时间以及每个标准时间段内帮助参考的数量,并将其用作界面修改的指南。第256页

Once the first interactive prototype is built, you can collect a variety of qualitative and quantitative data that will assist in evaluating the interface. To collect qualitative data, questionnaires that allow users to assess the interface prototype can be distributed. If quantitative data are desired, a form of time-study analysis can be conducted. Users are observed during interaction, and data—such as number of tasks correctly completed over a standard time period, frequency of actions, sequence of actions, time spent “looking” at the display, number and types of errors, error recovery time, time spent using help, and number of help references per standard time period—are collected and used as a guide for interface modification.Page 256

我们将在第 21 章中更详细地讨论测试虚拟环境的任务。然而,对用户界面评估方法的完整讨论超出了本书的范围。有关更多信息,请参阅 [Gao14]、[Hus15]、[Hac98] 和 [Sto05]。

We discuss the task of testing virtual environments in more detail in Chapter 21. However, a complete discussion of user interface evaluation methods is beyond the scope of this book. For further information, see [Gao14], [Hus15], [Hac98], and [Sto05].

12.8 可用性和可访问性

12.8 Usability and Accessibility

每个用户界面(无论是为 Web、移动设备、传统软件应用程序、消费产品还是工业设备设计)都应展现可用性侧栏中描述的可用性特征。Dix [Dix99] 认为移动界面应该回答三个主要问题:我在哪里?我现在能做什么?我去过哪里,还能去哪里?这些问题的答案使用户能够了解上下文并更有效地通过应用程序进行导航。

Every user interface—whether it is designed for the Web, a mobile device, a traditional software application, a consumer product, or an industrial device—should exhibit the usability characteristics that are described in the sidebar on usability. Dix [Dix99] argues that mobile interfaces should answer three primary questions: Where am I? What can I do now? Where have I been and where can I go? Answers to these questions allow a user to understand context and navigate more effectively through the app.

第257页

Page 257

12.8.1 可用性指南

12.8.1 Usability Guidelines

软件产品的用户界面是其“第一印象”。无论其内容的价值、处理能力和服务的复杂性以及应用程序本身的整体利益如何,设计不当的界面都会让潜在用户失望,并且实际上可能导致用户转向其他地方。由于几乎每个主题领域都有大量相互竞争的网络和移动应用程序,因此界面必须立即“抓住”潜在用户。

The user interface of a software product is its “first impression.” Regardless of the value of its content, the sophistication of its processing capabilities and services, and the overall benefit of the application itself, a poorly designed interface will disappoint the potential user and may, in fact, cause the user to go elsewhere. Because of the sheer volume of competing Web and mobile apps in virtually every subject area, the interface must “grab” a potential user immediately.

当然,传统应用程序和移动应用程序之间存在重要差异。由于小型移动设备(例如智能手机)所施加的物理限制,移动界面设计者必须以集中的方式压缩交互。然而,本节讨论的基本原则仍然适用。

There are, of course, important differences between conventional and mobile apps. By virtue of the physical constraints imposed by small mobile devices (e.g., smartphones), the mobile interface designer must compress interaction in a focused manner. However, the basic principles discussed in this section continue to apply.

Bruce Tognozzi [Tog01] 定义了一组可带来更好可用性的基本设计原则:10

Bruce Tognozzi [Tog01] defines a set of fundamental design principles that lead to better usability:10

预期。 应用程序的设计应该能够预测用户的下一步行动。例如,用户请求了一个内容对象,该内容对象呈现有关新版本操作系统的打印机驱动程序的信息。WebApp 的设计者应该预见到用户可能会请求下载驱动程序,并且应该提供允许直接发生这种情况的导航设施。

Anticipation. An application should be designed so that it anticipates the user’s next move. For example, a user has requested a content object that presents information about a printer driver for a new version of an operating system. The designer of the WebApp should anticipate that the user might request a download of the driver and should provide navigation facilities that allow this to happen directly.

沟通。 界面应传达用户发起的任何活动的状态。通信可以是显而易见的(例如,文本消息),也可以是微妙的(例如,一张纸的图像在打印机中移动以指示打印正在进行中)。

Communication. The interface should communicate the status of any activity initiated by the user. Communication can be obvious (e.g., a text message) or subtle (e.g., an image of a sheet of paper moving through a printer to indicate that printing is under way).

一致性。 导航控件、菜单、图标和美观(例如颜色、形状、布局)的使用应始终保持一致。例如,如果移动应用程序在显示屏底部使用一组四个图标(代表主要功能),则这些图标应出现在每个屏幕上,并且不应移动到显示屏顶部。图标的含义在应用程序的上下文中应该是不言而喻的。

Consistency. The use of navigation controls, menus, icons, and aesthetics (e.g., color, shape, layout) should be consistent throughout. For example, if a mobile app uses a set of four icons (to represent major functions) across the bottom of the display, these icons should appear on every screen and should not be moved to the top of the display. The meaning of the icons should be self-evident within the context of the app.

受控自主。 界面应该促进用户在整个应用程序中的移动,但它应该以强制执行为应用程序建立的导航约定的方式来实现。例如,导航到需要受控访问的内容应由用户 ID 和密码控制,并且不应存在使用户能够规避这些控制的导航机制。

Controlled Autonomy. The interface should facilitate user movement throughout the application, but it should do so in a manner that enforces navigation conventions that have been established for the application. For example, navigation to content requiring controlled access should be controlled by userID and password, and there should be no navigation mechanism that enables a user to circumvent these controls.

效率。 应用程序及其界面的设计应该优化用户的工作效率,而不是设计和构建它的开发人员或执行它的客户端-服务器环境的效率。Tognozzi [Tog01] 对此进行了讨论,他写道:“这个简单的事实就是它对每个人都如此重要的原因。。。认识到将用户生产力目标作为第一目标的重要性,并了解构建高效的[应用程序]和为高效的用户提供支持之间的重要区别。”

Efficiency. The design of the application and its interface should optimize the user’s work efficiency, not the efficiency of the developer who designs and builds it or the client-server environment that executes it. Tognozzi [Tog01] discusses this when he writes: “This simple truth is why it is so important for everyone . . . to appreciate the importance of making user productivity goal one and to understand the vital difference between building an efficient [application] and empowering an efficient user.”

第258页灵活性。 界面应该足够灵活,以使某些用户能够直接完成任务,而其他用户则能够以某种随机的方式探索应用程序。在每种情况下,它都应该使用户能够了解他所在的位置,并为用户提供可以撤消错误和回溯选择不当的导航路径的功能。

Page 258Flexibility. The interface should be flexible enough to enable some users to accomplish tasks directly and others to explore the application in a somewhat random fashion. In every case, it should enable the user to understand where he is and provide the user with functionality that can undo mistakes and retrace poorly chosen navigation paths.

重点。 界面(及其呈现的内容)应始终专注于用户手头的任务。这个概念对于移动应用程序尤其重要,因为设计者尝试做太多事情可能会变得非常混乱。

Focus. The interface (and the content it presents) should stay focused on the user task(s) at hand. This concept is particularly important for mobile apps that can become very cluttered in the designer’s attempts to do too much.

人机界面对象。 已经为 Web 和移动应用程序开发了一个庞大的可重用人机界面对象库。使用它们。最终用户可以“看到、听到、触摸或以其他方式感知”[Tog01]的任何界面对象都可以从多个对象库中的任何一个获取。

Human Interface Objects. A vast library of reusable human interface objects has been developed for both Web and mobile apps. Use them. Any interface object that can be “seen, heard, touched or otherwise perceived” [Tog01] by an end user can be acquired from any one of a number of object libraries.

减少延迟。 应用程序不应让用户等待某些内部操作完成(例如,下载复杂的图形图像),而应使用多任务处理,让用户继续工作,就像操作已完成一样。除了减少延迟之外,还必须承认延迟,以便用户了解发生了什么。这包括 (1) 当选择不会导致应用程序立即执行操作时提供音频反馈,(2) 显示动画时钟或进度条以指示处理正在进行中,以及 (3) 提供一些娱乐(例如,动画或文本演示),同时进行冗长的处理。

Latency Reduction. Rather than making the user wait for some internal operation to complete (e.g., downloading a complex graphical image), the application should use multitasking in a way that lets the user proceed with work as if the operation has been completed. In addition to reducing latency, delays must be acknowledged so that the user understands what is happening. This includes (1) providing audio feedback when a selection does not result in an immediate action by the application, (2) displaying an animated clock or progress bar to indicate that processing is under way, and (3) providing some entertainment (e.g., an animation or text presentation) while lengthy processing occurs.

易学性。 应用程序界面的设计应尽量减少学习时间,并且一旦学会后,应尽量减少重新访问应用程序时所需的重新学习。一般来说,界面应该强调简单、直观的设计,将内容和功能组织到对用户来说显而易见的类别中。

Learnability. An application interface should be designed to minimize learning time and, once learned, to minimize relearning required when the app is revisited. In general, the interface should emphasize a simple, intuitive design that organizes content and functionality into categories that are obvious to the user.

隐喻。 只要隐喻适合应用程序和用户,使用交互隐喻的界面就更容易学习和使用。隐喻是一个很好的主意,因为它们反映了现实世界的经验。只要确保您选择的隐喻为最终用户所熟知即可。隐喻应该引用用户体验中的图像和概念,但它不需要是现实世界体验的精确再现。

Metaphors. An interface that uses an interaction metaphor is easier to learn and easier to use, as long as the metaphor is appropriate for the application and the user. Metaphors are an excellent idea because they mirror real-world experience. Just be sure that the metaphor you choose is well known to end users. A metaphor should call on images and concepts from the user’s experience, but it does not need to be an exact reproduction of a real-world experience.

可读性。 通过界面呈现的所有信息都应该适合年轻人和老年人阅读。界面设计者应强调可读的字体样式、用户可控的字体大小以及增强对比度的颜色背景选择。

Readability. All information presented through the interface should be readable by young and old. The interface designer should emphasize readable type styles, user-controllable font sizes, and color background choices that enhance contrast.

轨道状态。 在适当的情况下,应跟踪和存储用户交互的状态,以便用户可以注销并稍后返回以从中断处继续。一般来说,cookie可以被设计用来存储状态信息。然而,cookie 是一项有争议的技术,其他设计解决方案可能更适合某些用户。

Track State. When appropriate, the state of the user interaction should be tracked and stored so that a user can log off and return later to pick up where he left off. In general, cookies can be designed to store state information. However, cookies are a controversial technology, and other design solutions may be more palatable for some users.

可见导航。 精心设计的界面提供了“用户在同一个地方,工作交给他们的错觉” [Tog01]。当使用这种方法时,导航不是用户关心的问题。相反,用户检索内容对象并选择通过界面显示和执行的功能。

Visible Navigation. A well-designed interface provides “the illusion that users are in the same place, with the work brought to them” [Tog01]. When this approach is used, navigation is not a user concern. Rather, the user retrieves the content object and selects functions that are displayed and executed through the interface.

第259页Nielsen 和 Wagner [Nie96] 针对界面设计提出了一些务实的“不该做”的建议(基于他们对主要 Web 应用程序的重新设计)。这些为本节前面建议的原则提供了很好的补充。

Page 259Nielsen and Wagner [Nie96] suggest a few pragmatic “don’ts” for interface design (based on their redesign of a major WebApp). These provide a nice complement to the principles suggested earlier in this section.

  • 不要强迫用户阅读大量文本,特别是当文本解释 WebApp 的操作或帮助导航时。

  • Don’t force the user to read voluminous amounts of text, particularly when the text explains the operation of the WebApp or assists in navigation.

  • 除非绝对不可避免,否则不要让用户滚动。

  • Don’t make users scroll unless it is absolutely unavoidable.

  • 不要依赖浏览器功能来辅助导航。

  • Don’t rely on browser functions to assist in navigation.

  • 不要让美观取代功能。

  • Don’t allow aesthetics to supersede functionality.

  • 不要强迫用户搜索显示以确定如何链接到其他内容或服务。

  • Don’t force the user to search the display to determine how to link to other content or services.

精心设计的界面可以提高用户对网站提供的内容或服务的感知。它不一定是华丽的,但它应该始终结构良好且符合人体工程学。关于可用性评估的其他建议可以在 [Gao14] 和 [Hus15} 中找到。

A well-designed interface improves the user’s perception of the content or services provided by the site. It need not necessarily be flashy, but it should always be well structured and ergonomically sound. Additional advice on usability evaluation can be found in [Gao14] and [Hus15}.

12.8.2 辅助功能指南

12.8.2 Accessibility Guidelines

随着用户界面设计的发展,四个常见的设计问题几乎总是浮出水面:系统响应时间、用户帮助设施、错误信息处理和命令标签。所有这些都可能导致所有用户的可访问性问题,而不仅仅是那些有特殊需求的用户。不幸的是,许多设计人员直到设计过程的较晚阶段才解决这些问题(有时直到可操作原型可用时才第一次意识到问题)。通常会导致不必要的迭代、项目延迟和最终用户的挫败感。最好将每个问题都确定为在软件设计之初就需要考虑的设计问题,这样更改很容易且成本较低。

As the design of a user interface evolves, four common design issues almost always surface: system response time, user help facilities, error information handling, and command labeling. All these can lead to accessibility issues for all users, not just those with special needs. Unfortunately, many designers do not address these issues until relatively late in the design process (sometimes the first inkling of a problem doesn’t occur until an operational prototype is available). Unnecessary iteration, project delays, and end-user frustration often result. It is far better to establish each as a design issue to be considered at the beginning of software design, when changes are easy and costs are low.

应用程序可访问性。随着计算应用程序变得无处不在,软件工程师必须确保界面设计包含能够使有特殊需求的人轻松访问的机制。出于道德、法律和商业原因,为可能存在身体障碍的用户(和软件工程师)提供无障碍环境是必要的。各种可访问性指南(例如,[W3C18])(许多是为 Web 应用程序设计的,但通常适用于所有类型的软件)为设计实现不同级别的可访问性的界面提供了详细的建议。其他人(例如,[App13]、[Mic13a] 和 [Zan18])提供了“辅助技术”的具体指南,以满足视觉、听觉、行动能力、言语和学习障碍人士的需求。

Application Accessibility. As computing applications become ubiquitous, software engineers must ensure that interface design encompasses mechanisms that enable easy access for those with special needs. Accessibility for users (and software engineers) that may be physically challenged is an imperative for ethical, legal, and business reasons. A variety of accessibility guidelines (e.g., [W3C18])—many designed for Web applications but often applicable to all types of software—provide detailed suggestions for designing interfaces that achieve varying levels of accessibility. Others (e.g., [App13], [Mic13a], and [Zan18]) provide specific guidelines for “assistive technology” that addresses the needs of those with visual, hearing, mobility, speech, and learning impairments.

响应时间。系统响应时间有两个重要特征:长度和可变性。如果系统响应时间太长,用户的挫败感和压力是不可避免的。可变性是指与平均响应时间的偏差,在许多方面,它是最重要的响应时间特性。低可变性使用户能够建立交互节奏,即使响应时间相对较长。例如,对命令的 1 秒响应通常优于 0.1 到 2.5 秒的响应。当变化很大时,用户总是会失去平衡,总是想知道幕后是否发生了“不同”的事情。

Response Time. System response time has two important characteristics: length and variability. If system response is too long, user frustration and stress are inevitable. Variability refers to the deviation from average response time, and in many ways, it is the most important response time characteristic. Low variability enables the user to establish an interaction rhythm, even if response time is relatively long. For example, a 1-second response to a command will often be preferable to a response that varies from 0.1 to 2.5 seconds. When variability is significant, the user is always off balance, always wondering whether something “different” has occurred behind the scenes.

第260页帮助设施。几乎每个基于计算机的交互式系统的用户都会时不时地需要帮助。现代软件应该提供在线帮助设施,使用户能够在不离开界面的情况下获得问题的答案或解决问题。

Page 260Help Facilities. Almost every user of an interactive, computer-based system requires help now and then. Modern software should provide online help facilities that enable a user to get a question answered or resolve a problem without leaving the interface.

错误处理。一般来说,交互系统产生的每个错误消息或警告都应具有以下特征:

Error Handling. In general, every error message or warning produced by an interactive system should have the following characteristics:

  1. 用用户可以理解的术语描述问题

  2. Describes the problem in jargon that the user can understand

  3. 提供从错误中恢复的建设性建议

  4. Provides constructive advice for recovering from the error

  5. 指示错误的任何负面后果(例如,可能损坏的数据文件),以便用户可以检查以确保它们没有发生(或者如果发生则纠正它们)

  6. Indicates any negative consequences of the error (e.g., potentially corrupted data files) so that the user can check to ensure that they have not occurred (or correct them if they have)

  7. 伴随听觉或视觉提示

  8. Be accompanied by an audible or visual cue

  9. 永远不应该将错误归咎于用户

  10. Should never place blame for the error on the user

菜单和命令标签。键入命令曾经是用户和系统软件之间最常见的交互模式,并且普遍用于各种类型的应用程序。如今,面向窗口的点击界面的使用减少了对键入命令的依赖,但一些高级用户仍然更喜欢面向命令的交互模式。当提供键入命令或菜单标签作为交互模式时,会出现许多设计问题:

Menu and Command Labeling. The typed command was once the most common mode of interaction between user and system software and was commonly used for applications of every type. Today, the use of window-oriented, point-and-pick interfaces has reduced reliance on typed commands, but some power-users continue to prefer a command-oriented mode of interaction. A number of design issues arise when typed commands or menu labels are provided as a mode of interaction:

  • 每个菜单选项都有对应的命令吗?

  • Will every menu option have a corresponding command?

  • 命令将采取什么形式?选项包括控制序列(例如 alt-P)、功能键或键入的单词。

  • What form will commands take? Options include a control sequence (e.g., alt-P), function keys, or a typed word.

  • 学习和记住命令有多困难?如果忘记命令怎么办?

  • How difficult will it be to learn and remember the commands? What can be done if a command is forgotten?

  • 用户可以自定义或缩写命令吗?

  • Can commands be customized or abbreviated by the user?

  • 菜单标签在界面上下文中是否不言自明?

  • Are menu labels self-explanatory within the context of the interface?

  • 子菜单与主菜单项所隐含的功能一致吗?

  • Are submenus consistent with the function implied by a master menu item?

  • 是否在一系列应用程序中建立了适当的命令使用约定?

  • Have appropriate conventions for command usage been established across a family of applications?

国际化。软件工程师及其经理总是低估了创建适应不同区域设置和语言需求的用户界面所需的工作量和技能。很多时候,界面是针对一种区域设置和语言设计的,然后临时调整以在其他国家/地区工作。界面设计师面临的挑战是创建“全球化”软件。也就是说,用户界面的设计应能够容纳可交付给所有使用该软件的人的通用核心功能。本地化功能使界面能够针对特定市场进行定制。

Internationalization. Software engineers and their managers invariably underestimate the effort and skills required to create user interfaces that accommodate the needs of different locales and languages. Too often, interfaces are designed for one locale and language and then jury-rigged to work in other countries. The challenge for interface designers is to create “globalized” software. That is, user interfaces should be designed to accommodate a generic core of functionality that can be delivered to all who use the software. Localization features enable the interface to be customized for a specific market.

软件工程师可以使用各种国际化指南(例如,[IBM13])。这些指南解决了广泛的设计问题(例如,屏幕布局在不同的市场中可能有所不同)和离散的实施问题(例如,不同的字母可能会产生专门的标签和间距要求)。Unicode标准 [Uni03]开发是为了解决管理数十种包含数百个字符和符号的自然语言的艰巨挑战。

A variety of internationalization guidelines (e.g., [IBM13]) are available to software engineers. These guidelines address broad design issues (e.g., screen layouts may differ in various markets) and discrete implementation issues (e.g., different alphabets may create specialized labeling and spacing requirements). The Unicode standard [Uni03] has been developed to address the daunting challenge of managing dozens of natural languages with hundreds of characters and symbols.

第261页

Page 261

12.9 传统软件用户体验和移动性

12.9 Conventional Software UX and Mobility

在本章前面,我们注意到所有用户界面设计都始于用户、任务和环境需求的识别。一旦识别了用户任务,就创建并分析用户场景(用例)以定义一组界面对象和操作。

Earlier in this chapter, we noted that all user interface design begins with the identification of user, task, and environmental requirements. Once user tasks have been identified, user scenarios (use cases) are created and analyzed to define a set of interface objects and actions.

需求模型中包含的信息构成了创建屏幕布局的基础,该屏幕布局描述了图形设计和图标的放置、描述性屏幕文本的定义、窗口的规范和标题以及主要和次要菜单项的规范。然后使用工具进行原型设计并最终实现界面设计模型。

Information contained within the requirements model forms the basis for the creation of a screen layout that depicts graphical design and placement of icons, definition of descriptive screen text, specification and titling for windows, and specification of major and minor menu items. Tools are then used to prototype and ultimately implement the interface design model.

在针对移动性进行设计时,开发人员需要更多地关注屏幕尺寸和用户交互设备的差异。软件产品的移动用户更有可能期望该产品能够根据他们的喜好轻松定制,并在积极使用应用程序时利用用户位置的变化。我们将在第 13 章重点讨论移动设备的设计。

When designing for mobility, developers need to pay more attention to differences in screen sizes and user interaction devices. Mobile users of a software product are more likely to expect the product to be easily customized to their preferences and to take advantage of changes in the user’s location when they are actively using the app. We will focus on designing for mobile devices in Chapter 13.

12.10 总结

12.10 Summary

用户界面可以说是基于计算机的系统或产品中最重要的元素。如果界面设计不佳,用户利用应用程序的计算能力和信息内容的能力可能会受到严重阻碍。事实上,一个薄弱的接口可能会导致一个设计良好且实施可靠的应用程序失败。

The user interface is arguably the most important element of a computer-based system or product. If the interface is poorly designed, the user’s ability to tap the computational power and informational content of an application may be severely hindered. In fact, a weak interface may cause an otherwise well-designed and solidly implemented application to fail.

指导有效用户界面设计的三个重要原则:(1) 让用户掌控,(2) 减少用户的记忆负载,(3) 使界面保持一致。为了实现遵守这些原则的界面,必须进行有组织的设计过程。

Three important principles guide the design of effective user interfaces: (1) place the user in control, (2) reduce the user’s memory load, and (3) make the interface consistent. To achieve an interface that abides by these principles, an organized design process must be conducted.

用户界面的开发从一系列分析任务开始。用户分析定义了各种最终用户的角色,并从各种业务和技术来源收集。用户分析允许开发人员创建客户旅程地图作为产品目标的可视化表示。任务分析使用精细化或面向对象的方法定义用户任务和操作,应用用例、任务和对象精细化、工作流分析和分层任务表示来充分理解人机交互。环境分析确定了界面必须在其中运行的物理和社会结构。

The development of a user interface begins with a series of analysis tasks. User analysis defines personas for the profiles of various end users and is gathered from a variety of business and technical sources. The user analysis allows the developers to create a customer journey map as a visual representation of the goals for the product. Task analysis defines user tasks and actions using either an elaborative or object-oriented approach, applying use cases, task and object elaboration, workflow analysis, and hierarchical task representations to fully understand the human-computer interaction. Environmental analysis identifies the physical and social structures in which the interface must operate.

分析使用场景后,创建界面对象和操作,并为创建屏幕布局提供基础,该屏幕布局描述图形设计和图标放置、描述性屏幕文本的定义、窗口的规范和标题以及主要和次要菜单的规范项目。可以创建故事板来说明通过为产品开发的屏幕进行导航以完成特定的用户任务。随着设计模型的完善,响应时间、命令和操作结构、错误处理和帮助设施等设计问题都得到了考虑。使用各种实现工具来构建原型以供用户评估。第262页

After analyzing usage scenarios, interface objects and actions are created and provide a basis for the creation of a screen layout that depicts graphical design and placement of icons, definition of descriptive screen text, specification and titling for windows, and specification of major and minor menu items. A storyboard may be created to illustrate the navigation through screens developed for the product to accomplish specific user tasks. Design issues such as response time, command and action structure, error handling, and help facilities are considered as the design model is refined. A variety of implementation tools are used to build a prototype for evaluation by the user.Page 262

与传统软件的界面设计一样,移动应用程序界面设计描述了用户界面的结构和组织,包括屏幕布局的表示、交互模式的定义以及导航机制的描述。一组界面设计原则和界面设计工作流程指导移动应用程序设计人员设计布局和界面控制机制。

Like interface design for conventional software, the design mobile app interface describes the structure and organization of the user interface and includes a representation of screen layout, a definition of the modes of interaction, and a description of navigation mechanisms. A set of interface design principles and an interface design workflow guide the mobile app designer when layout and interface control mechanisms are designed.

用户界面是进入软件的窗口。在许多情况下,界面塑造了用户对系统质量的看法。如果“窗口”被弄脏、呈波浪形或破损,用户可能会拒绝原本功能强大的基于计算机的系统。界面中的可用性和可访问性问题也可能导致用户寻找更能满足其需求和期望的替代产品。

The user interface is the window into the software. In many cases, the interface molds a user’s perception of the quality of the system. If the “window” is smudged, wavy, or broken, the user may reject an otherwise powerful computer-based system. Usability and accessibility issues in the interface may also cause users to find an alternative product that better meets their needs and expectations.

问题与思考点

Problems and Points to Ponder

12.1。描述您曾经使用过的最糟糕的界面,并根据本章介绍的概念对其进行批评。描述您曾经使用过的最佳界面,并根据本章介绍的概念对其进行批评。

12.1. Describe the worst interface that you have ever worked with and critique it relative to the concepts introduced in this chapter. Describe the best interface that you have ever worked with and critique it relative to the concepts introduced in this chapter.

12.2. 考虑以下交互式应用程序之一(或由您的讲师指定的应用程序):

12.2. Consider one of the following interactive applications (or an application assigned by your instructor):

  1. 桌面出版系统

  2. A desktop publishing system

  3. 计算机辅助设计系统

  4. A computer-aided design system

  5. 室内设计系统(如第 12.4.2 节所述)

  6. An interior design system (as described in Section 12.4.2)

  7. 大学自动课程注册系统

  8. An automated course registration system for a university

  9. 一个图书馆管理系统

  10. A library management system

  11. 基于互联网的公共选举投票站

  12. An Internet-based polling booth for public elections

  13. 家庭银行系统

  14. A home banking system

  15. 由您的讲师分配的交互式应用程序

  16. An interactive application assigned by your instructor

为这些系统中的任何一个开发用户模型、设计模型、心智模型和实现模型。

Develop a user model, design model, mental model, and an implementation model, for any one of these systems.

12.3。对问题 12.2中列出的任一系统执行详细的任务分析。

12.3. Perform a detailed task analysis for any one of the systems listed in Problem 12.2.

12.4。为问题 12.2中列出的系统之一创建客户旅程图。

12.4. Create a customer journey map for one of the systems listed in Problem 12.2.

12.5。继续问题 12.2,为您选择的应用程序定义接口对象和操作。识别每个对象类型。

12.5. Continuing Problem 12.2, define interface objects and actions for the application you have chosen. Identify each object type.

12.6。开发一组屏幕布局并将它们组织成您在问题 12.2中选择的系统的故事板。

12.6. Develop a set of screen layouts and organize them into a storyboard for the system you chose in Problem 12.2.

12.7。使用 Keynote 等原型设计工具为您在问题 12.6中创建的故事板创建交互式原型。

12.7. Use a prototyping tool like Keynote to create an interactive prototype for the storyboard you created in Problem 12.6.

12.8。描述您的任务分析设计模型的用户帮助工具方法以及您在问题 12.3、12.4和12.5执行的任务分析。第263页

12.8. Describe your approach to user help facilities for the task analysis design model and task analysis you performed as part of Problems 12.3, 12.4, and 12.5.Page 263

12.9。提供一些示例来说明为什么响应时间可变性可能是一个问题。

12.9. Provide a few examples that illustrate why response time variability can be an issue.

12.10。开发一种自动集成错误消息和用户帮助工具的方法。也就是说,系统会自动识别错误类型并提供帮助窗口以及纠正错误的建议。执行合理完整的软件设计,考虑适当的数据结构和算法。

12.10. Develop an approach that would automatically integrate error messages and a user help facility. That is, the system would automatically recognize the error type and provide a help window with suggestions for correcting it. Perform a reasonably complete software design that considers appropriate data structures and algorithms.

12.11。制定一份界面评估调查问卷,其中包含 20 个适用于大多数界面的通用问题。让 10 名同学完成你们都使用的交互式系统的调查问卷。总结结果,并向全班报告。

12.11. Develop an interface evaluation questionnaire that contains 20 generic questions that would apply to most interfaces. Have 10 classmates complete the questionnaire for an interactive system that you all use. Summarize the results, and report them to your class.

1请参阅 https://www.usability.gov/what-and-why/interaction-design.html。

1 See https://www.usability.gov/what-and-why/interaction-design.html.

2有理由认为本节应放在第 8 章中,因为其中讨论了需求分析问题。之所以将其定位在这里,是因为用户体验分析和设计是紧密相连的,而两者之间的界限往往是模糊的。

2 It is reasonable to argue that this section should be placed in Chapter 8, since requirements analysis issues are discussed there. It has been positioned here because user experience analysis and design are intimately connected to one another, and the boundary between the two is often fuzzy.

3认知演练是一种评估系统中提示和提示的顺序是否支持人们处理任务的方式的方法,并通过让用户在使用系统表示的同时口头表达他们的决策过程来预测系统的“下一步”完成一个用户目标。

3 A cognitive walkthrough is a method that evaluates whether the order of cues and prompts in a system supports the way people process tasks and anticipates the “next steps” of a system by having users verbalize their decision-making process while using a system representation to complete a user goal.

4然而,情况可能并非如此。室内设计师可能想要指定要绘制的透视图、比例、颜色的使用和其他信息。与绘制透视图相关的用例将提供解决此任务所需的信息。

4 However, this may not be the case. The interior designer might want to specify the perspective to be drawn, the scaling, the use of color, and other information. The use case related to drawing perspective renderings would provide the information you need to address this task.

5请参阅 https://keynotopia.com/。

5 See https://keynotopia.com/.

6请注意,这与前面章节中这些功能的实现有些不同。这可能被认为是基于新房间布局应用程序的初稿设计。

6 Note that this differs somewhat from the implementation of these features in earlier chapters. This might be considered a first-draft design based on the new room layout app.

7有关解决用户界面模式的网站的有用建议,请访问 https://www.interaction-design.org/literature/article/10-great-sites-for-ui-design-patterns。

7 Useful suggestions for sites that address user interface patterns can be found at https://www.interaction-design.org/literature/article/10-great-sites-for-ui-design-patterns.

8值得注意的是,人体工程学和界面设计专家也可能对界面进行审查。这些评论称为启发式评估认知演练。

8 It is important to note that experts in ergonomics and interface design may also conduct reviews of the interface. These reviews are called heuristic evaluations or cognitive walk-throughs.

9一些软件工程师更喜欢开发一个称为纸质原型的低保真用户界面 (UI) 模型,以允许利益相关者在提交任何编程资源之前测试 UI 概念。该过程如下所述:http://www.paperprototyping.com/what_examples.html。

9 Some software engineers prefer to develop a low-fidelity mockup of the user interface (UI) called a paper prototype to allow stakeholders to test the UI concept before committing any programming resources. The process is described here: http://www.paperprototyping.com/what_examples.html.

10 Tognozzi 的原始原理已在本书中进行了改编和扩展。有关这些原则的进一步讨论,请参阅 [Tog01]。

10 Tognozzi’s original principles have been adapted and extended for use in this book. See [Tog01] for further discussion of these principles.

第264页

Page 264

章节

chapter

13移动性设计

13 Design for Mobility

移动设备(智能手机、平板电脑、可穿戴设备、手持游戏设备和其他专用产品)已成为计算的新面貌。根据皮尤研究中心 [Pew18] 的数据,在美国,77% 的人拥有智能手机,50% 的人拥有某种平板电脑。移动计算已成为主导力量。

Mobile devices—smartphones, tablets, wearable devices, handheld gaming devices, and other specialized products—have become the new face of computing. According to Pew Research Center [Pew18], in the United States 77 percent of people own a smartphone and 50 percent of people own a tablet computer of some kind. Mobile computing has become a dominant force.

第265页Jakob Nielsen [Nie00] 在他关于网页设计的权威著作中指出:“设计本质上有两种基本方法:表达自己的艺术理想和为客户解决问题的工程理想。” 在移动开发的第一个十年中,艺术理念是许多开发人员选择的方法。设计以临时方式进行,通常在生成 HTML 时进行。设计源于随着网页构造的发生而演变的艺术视野。

Page 265In his authoritative book on Web design, Jakob Nielsen [Nie00] states: “There are essentially two basic approaches to design: the artistic ideal of expressing yourself and the engineering ideal of solving a problem for a customer.” During the first decade of mobile development, the artistic idea was the approach that many developers chose. Design occurred in an ad hoc manner and was usually conducted as HTML was generated. Design evolved out of an artistic vision that evolved as Web page construction occurred.

即使在今天,许多开发人员仍将移动应用程序用作“有限设计”的典型代表。他们认为,移动市场的即时性和波动性不利于正式设计;该设计随着应用程序的构建(编码)而不断发展,并且应该花费相对较少的时间来创建详细的设计模型。这个论点有其道理,但仅适用于相对简单的应用程序。当内容和功能复杂时;当移动应用程序的大小包含数百或数千个内容对象、功能和分析类时;当应用程序的成功将直接影响业务的成功时,设计不能也不应该掉以轻心。这一现实引导我们采用尼尔森的第二种方法——“为客户解决问题的工程理想”。

Even today, many developers use mobile apps as poster children for “limited design.” They argue that immediacy and volatility of the mobile market mitigate against formal design; that design evolves as an application is built (coded), and that relatively little time should be spent on creating a detailed design model. This argument has merit, but only for relatively simple apps. When content and function are complex; when the size of the mobile app encompasses hundreds or thousands of content objects, functions, and analysis classes; and when the success of the app will have a direct impact on the success of the business, design cannot and should not be taken lightly. This reality leads us to Nielsen’s second approach—“the engineering ideal of solving a problem for a customer.”

13.1 挑战

13.1 The Challenges

尽管移动设备彼此之间有许多共同的功能,但它们的用户对于他们期望在每个设备中捆绑哪些功能通常有非常不同的看法。一些用户期望他们的个人计算机上提供相同的功能。其他人则关注便携式设备赋予他们的自由,并乐意接受熟悉的软件产品的移动版本中减少的功能。还有一些人期望传统计算或娱乐设备上无法实现的独特体验。用户对“好”的看法可能比移动产品本身的任何技术质量维度更重要。

Although mobile devices have many features in common with each other, their users often have very different perceptions of what features they expect to be bundled in each. Some users expect the same features that are provided on their personal computers. Others focus on the freedom that portable devices give them and gladly accept the reduced functionality in the mobile version of a familiar software product. Still others expect unique experiences not possible on traditional computing or entertainment devices. The user’s perception of “goodness” might be more important than any of the technical quality dimensions of the mobile product itself.

13.1.1 开发注意事项

13.1.1 Development Considerations

与所有计算设备一样,移动平台的差异化在于其提供的软件——操作系统(例如 Android 或 iOS)与提供广泛功能的数十万种移动软件产品中的一小部分的组合。新工具允许未经多少正式培训的个人与大型软件开发团队开发的其他应用程序一起创建和销售应用程序。

Like all computing devices, mobile platforms are differentiated by the software they deliver—a combination of operating system (e.g., Android or iOS) and a small subset of the hundreds of thousands of mobile software products that provide a very wide range of functionality. New tools allow individuals with little formal training to create and sell apps alongside other apps developed by large teams of software developers.

尽管业余爱好者可以开发应用程序,但许多软件工程师认为移动应用程序是当今构建的最具挑战性的软件系统之一 [Voa12]。移动平台非常复杂。Android 和 iOS 操作系统都包含超过 1200 万行代码。移动设备通常具有迷你浏览器,它们不会显示网页上可用的全套内容。不同的移动设备使用不同的操作系统和依赖于平台的开发环境。与个人电脑相比,移动设备往往具有更小的屏幕尺寸和更多样的屏幕尺寸。这可能需要更多地关注用户界面设计问题,包括限制某些内容显示的决定。移动应用程序的设计必须考虑间歇性连接中断、电池寿命限制以及其他设备限制1 [Whi08]。第266页

Even though apps can be developed by amateurs, many software engineers think that MobileApps are among the most challenging software systems being built today [Voa12]. Mobile platforms are very complex. Both the Android and iOS operating systems contain over 12 million lines of code. Mobile devices often have mini browsers that will not display the full set of content available on a Web page. Different mobile devices use different operating systems and platform-dependent development environments. Mobile devices tend to have smaller screen sizes and more varied screen sizes than personal computers. This may require greater attention to user interface design issues, including decisions to limit display of some content. MobileApps must be designed to take intermittent connectivity outages into account, limitations on battery life, and other device constraints1 [Whi08].Page 266

移动计算环境中的系统组件在应用程序运行时可能会改变其位置。为了维持游牧网络的连接性,必须开发两种协调机制,用于发现设备、交换信息、维护安全和通信完整性以及同步操作。移动产品设计的安全性和其他元素之间始终需要权衡。

System components in mobile computing environments are likely to change their locations while their apps are running. To maintain connectivity in nomadic networks,2 coordination mechanisms for discovering devices, exchanging information, maintaining security and communication integrity, and synchronizing actions must be developed. There is always a trade-off between security and other elements of the mobile product design.

此外,软件工程师必须在移动应用程序的表达能力和利益相关者的安全问题之间确定适当的设计权衡。开发人员必须寻求发现节能算法(或调整现有算法),以尽可能节省电池电量。可能必须创建中间件以允许不同类型的移动设备在同一移动网络中相互通信[Gru00]。

In addition, software engineers must identify the proper design trade-offs between the expressive power of the MobileApp and stakeholder security concerns. Developers must seek to discover algorithms (or adapt existing algorithms) that are energy efficient to conserve battery power when possible. Middleware may have to be created to allow different types of mobile devices to communicate with each other in the same mobile networks [Gru00].

软件工程师应该利用设备特性和上下文感知应用程序来打造用户体验。非功能性需求(例如安全性、性能、可用​​性)与 Web 应用程序或桌面软件应用程序的需求有些不同。安全性和移动设计的其他元素之间始终需要权衡。测试移动软件产品(第 21 章)带来了额外的挑战,因为用户期望他们将在大量不同的物理环境中工作。可移植性是软件工程师面临的另一个挑战,因为有多种流行的设备平台。为多个设备平台开发和支持应用程序的成本很高[Was10]。

Software engineers should craft a user experience that takes advantage of device characteristics and context-aware applications. The nonfunctional requirements (e.g., security, performance, usability) are a bit different from those for either WebApps or desktop software applications. There is always a trade-off between security and other elements of the mobile design. Testing mobile software products (Chapter 21) provides additional challenges because users expect that they will work in a large number of physically different environments. Portability is another challenge for software engineers as there are several popular device platforms. It is expensive to develop and support applications for multiple device platforms [Was10].

13.1.2 技术考虑

13.1.2 Technical Considerations

向电话、相机和电视等日常设备添加 Web 功能的低成本正在改变人们访问信息和使用网络服务的方式 [Sch11]。移动应用程序应解决的众多技术考虑因素包括:

The low cost of adding Web capabilities to everyday devices such as phones, cameras, and TVs is transforming the way people access information and use network services [Sch11]. Among the many technical considerations that MobileApps should address are the following:

  • 多种硬件和软件平台。移动产品在许多不同的平台(移动和固定)上运行并具有一系列不同级别的功能并不罕见。造成这些差异的部分原因是设备之间可用的硬件和软件有很大不同。这增加了开发成本和时间。它还会使配置管理(第 22 章)变得更加困难。

  • Multiple hardware and software platforms. It is not at all unusual for a mobile product to run on many different platforms (both mobile and stationary) with a range of differing levels of functionality. The reasons for these differences are in part because the hardware and software available are quite different from device to device. This increases both development cost and time. It also can make configuration management (Chapter 22) more difficult.

  • 许多开发框架和编程语言。目前,移动产品采用多种不同的编程或脚本语言(例如 HTML5、JavaScript、Java、Swift 和 C#)针对多种流行的开发框架(例如 Android、iOS、Xamarin、Windows、AngularJS)编写。很少有移动设备允许在设备本身上进行直接开发。相反,移动开发人员通常使用在桌面开发系统上运行的模拟器。这些模拟器可能会也可能不会准确地反映设备本身的局限性。瘦客户端应用程序通常比专门在移动设备上运行的应用程序更容易移植到多个设备。第267页

  • Many development frameworks and programming languages. Mobile products are currently being written in several distinct programming or scripting languages (e.g., HTML5, JavaScript, Java, Swift, and C#) for a multitude of popular development frameworks (e.g., Android, iOS, Xamarin, Windows, AngularJS). Very few mobile devices allow direct development on a device itself. Instead, mobile developers typically use emulators running on desktop development systems. These emulators may or may not accurately reflect the limitations of the device itself. Thin-client applications are often easier to port to multiple devices than applications designed to run exclusively on the mobile device.Page 267

  • 许多应用程序商店具有不同的规则和工具。每个移动平台都有自己的应用程序商店和自己的接受应用程序的标准(例如,Apple、3 Google、4 Microsoft、5和 Amazon 6发布自己的标准)。面向多个平台的移动产品的开发必须分开进行,每个版本的应用程序都需要自己的标准专家。

  • Many app stores with different rules and tools. Each mobile platform has its own app store and its own standards for accepting apps (e.g., Apple,3 Google,4 Microsoft,5 and Amazon6 publish their own standards). Development of a mobile product for multiple platforms must proceed separately, and each version of the app needs its own standards expert.

  • 开发周期非常短。移动产品市场竞争非常激烈,软件工程师在构建移动应用程序时可能会利用敏捷开发流程来减少开发时间 [Was10]。

  • Very short development cycles. The marketplace for mobile products is very competitive, and software engineers are likely to make use of agile development processes when building MobileApps in an effort to reduce development time [Was10].

  • 用户界面的限制以及与传感器和摄像头交互的复杂性。移动设备的屏幕尺寸比个人电脑更小,并且具有更丰富的交互可能性(触摸、手势、摄像头等)和基于上下文感知的使用场景。用户界面的风格和外观通常由特定于平台的开发工具的性质决定[Rot02]。允许智能设备与智能空间交互提供了创建个性化、网络化、高保真应用平台的潜力,例如通过合并智能手机和汽车信息娱乐系统所看到的平台。7

  • User interface limitations and complexities of interaction with sensors and cameras. Mobile devices have smaller screen sizes than personal computers and a richer set of interaction possibilities (touch, gesture, camera, etc.) and usage scenarios based on context awareness. The style and appearance of the user interface is often dictated by the nature of platform-specific development tools [Rot02]. Allowing smart devices to interact with smart spaces offers the potential to create personalized, networked, high-fidelity application platforms such as those seen by merging smartphones and car infotainment systems.7

  • 有效利用上下文。用户期望移动应用能够根据设备相对于可用网络功能的物理位置提供个性化的用户体验。用户界面设计和上下文感知应用程序将在第 13.4 节中进行更详细的讨论。

  • Effective use of context. Users expect MobileApps to deliver personalized user experiences based on the physical location of a device in relation to the available network features. User interface design and context-aware applications are discussed in greater detail in Section 13.4.

  • 能源管理。电池寿命通常是许多移动设备的最大限制因素之一。背光、读写内存、使用无线连接、使用专用硬件和处理器速度都会影响功耗,需要软件开发人员考虑[Mei09]。

  • Power management. Battery life is often one of the most limiting constraints on many mobile devices. Backlighting, reading and writing to memory, using wireless connections, making use of specialized hardware, and processor speed all impact power usage and need to be considered by software developers [Mei09].

  • 安全和隐私模型和政策。无线通信很难防止窃听。防止汽车应用中的中间人攻击8对于用户的安全至关重要 [Bos11]。如果设备丢失或下载恶意应用程序,存储在移动设备上的数据可能会被盗。提高移动应用程序安全和隐私信心水平的软件策略通常会降低应用程序的可用性和用户之间通信的自发性 [Rot02]。

  • Security and privacy models and policies. Wireless communication is difficult to protect from eavesdropping. Preventing man-in-the-middle-attacks8 in automotive applications can be critical to the safety of the users [Bos11]. Data stored on a mobile device are subject to theft if a device is lost or a malicious app is downloaded. Software policies that increase the level of confidence in the security and privacy of a MobileApp often reduce the usability of the app and the spontaneity of the communication among users [Rot02].

  • 第268页计算和存储限制。人们对使用移动设备控制家庭环境和安全服务非常感兴趣。当移动应用程序被允许与其环境中的设备和服务交互时,大量的信息很容易压垮移动设备(存储、处理速度、功耗)[Spa11]。开发人员可能需要寻找编程捷径和减少对处理器和内存资源需求的方法。

  • Page 268Computational and storage limitations. There is great interest in using mobile devices to control home environmental and security services. When MobileApps are allowed to interact with devices and services in their environment, it is easy to overwhelm the mobile device (storage, processing speed, power consumed) with the sheer volume of information [Spa11]. Developers may need to look for programming shortcuts and means of reducing the demands made on processor and memory resources.

  • 依赖于外部服务的应用程序。构建瘦移动客户端意味着需要依赖 Web 服务提供商和云存储设施。这增加了对数据或服务可访问性和安全性的担忧[Rot02]。

  • Applications that depend on external services. Building thin mobile clients suggests the need to rely on Web service providers and cloud storage facilities. This increases concerns for both data or service accessibility and security [Rot02].

  • 测试复杂性。完全在设备上运行的移动产品可以使用传统的软件测试方法(第19章和第20章)或使用在个人计算机上运行的模拟器进行测试。瘦客户端移动应用程序的测试尤其具有挑战性。它们表现出许多与 Web 应用程序中相同的测试挑战,但它们还有与通过互联网网关和电话网络传输数据相关的额外问题 [Was10]。移动软件产品的测试将在第 21 章中讨论。

  • Testing complexity. Mobile products that run entirely on the device can be tested using traditional software testing methods (Chapters 19 and 20) or using emulators running on personal computers. Thin-client MobileApps are particularly challenging to test. They exhibit many of the same testing challenges found in WebApps, but they have the additional concerns associated with transmission of data through Internet gateways and telephone networks [Was10]. Testing of mobile software products will be discussed in Chapter 21.

13.2 移动开发生命周期

13.2 Mobile Development Life Cycle

Burns [Bur16] 和她的 Microsoft 同事描述了对迭代移动 SDLC 的建议,其中包含五个主要阶段:

Burns [Bur16] and her Microsoft colleagues describe a recommendation for an iterative mobile SDLC that contains five major stages:

成立。确定移动产品的目标、特性和功能,以确定第一个增量或可行性原型的范围和规模。开发人员和利益相关者必须意识到人类、社会、文化和组织活动,这些活动可能揭示用户需求的隐藏方面并影响所提议的移动产品的业务目标和功能。

Inception. Goals, features, and functions of the mobile product are identified to determine the scope and the size of the first increment or feasibility prototype. Developers and stakeholders must be conscious of human, social, cultural, and organizational activities that may reveal hidden aspects of the users’ needs and affect the business targets and functionality of the proposed mobile product.

设计。设计包括架构设计、导航设计、界面设计、内容设计。开发人员使用屏幕模型和纸质原型来定义应用程序用户体验,以帮助创建适当的用户界面设计,该设计将考虑不同的屏幕尺寸和功能以及每个目标平台的功能。

Design. The design includes architectural design, navigation design, interface design, content design. Developers define the app user experience using screen mockups and paper prototypes to help create a proper user interface design that will take different screen sizes and capabilities into account as well as the capabilities of each targeted platform.

发展。移动软件是经过编码的、功能性的和非功能性的。随着产品的发展,创建和执行测试用例,并进行可用性和可访问性评估。

Development. Mobile software is coded, functional and nonfunctional. Test cases are created and executed, and usability and accessibility evaluations are conducted as the product evolves.

稳定。大多数移动产品都会经历一系列原型:可行性原型,旨在作为概念证明,可能只有一个完整的逻辑路径贯穿应用程序;alpha 原型,包含最小可行产品的功能;beta 原型,基本完整并包含大多数经过测试的功能;最后是候选版本,其中包含所有必需的功能,所有计划的测试都已完成,并且已准备好供产品所有者审核。

Stabilization. Most mobile products go through a series of prototypes: feasibility prototype, intended as a proof of concept with perhaps only one complete logic path through the application; alpha prototype, which contains the functionality for minimum viable product; beta prototype, which is largely complete and contains most tested functionality; and lastly the release candidate, which contains all required functionality, for which all scheduled tests have been completed, and which is ready for review by the product owner.

第269页部署。一旦稳定,移动产品将由商业应用商店审核并可供销售和下载。对于仅供公司内部使用的应用程序,在部署之前可能需要进行产品所有者审核。

Page 269Deployment. Once stabilized, a mobile product is reviewed by a commercial app store and made available for sale and download. For apps intended for internal company use only, a product owner review may be all that is required before deployment.

移动开发利用敏捷的螺旋式工程流程模型。这些阶段并不像使用瀑布模型完成移动开发那样按顺序完成。随着开发人员和利益相关者更好地了解用户需求和产品业务目标,上述阶段会被重复访问。

Mobile development makes use of an agile, spiral engineering process model. The stages are not completed in order like they would be if mobile development was done using the waterfall model. The stages described above are visited repeatedly as developers and stakeholders gain better understanding of the user needs and product business goals.

13.2.1 用户界面设计

13.2.1 User Interface Design

移动设备用户期望掌握移动应用程序所需的学习时间最少。为了实现这一目标,移动应用程序设计人员在多个平台上使用一致的图标表示和放置。此外,设计者必须对用户对于在移动设备屏幕上显示个人信息的隐私期望保持敏感。触摸和手势界面,以及复杂的语音输入和面部识别,正在迅速成熟[Shu12],并且已经成为用户界面设计师工具箱的一部分。

Mobile device users expect that minimal learning time will be required to master a MobileApp. To achieve this, MobileApp designers use consistent icon representations and placement across multiple platforms. In addition, designers must be sensitive to the user’s expectation of privacy with regard to the display of personal information on the screen of the mobile device. Touch and gesture interfaces, along with sophisticated voice input and facial recognition, are maturing rapidly [Shu12] and have already become part of the user interface designer’s toolbox.

提供所有人访问的法律和道德压力表明,移动设备界面需要考虑品牌差异、文化差异、计算体验差异、老年用户和残疾用户(例如,视觉、听觉、移动性)。可用性差的影响可能意味着用户无法完成他们的任务或对结果不满意。这表明在每个可用性领域(用户界面、外部附件界面和服务界面)中以用户为中心的设计活动的重要性。可访问性是一个重要的设计问题,在应用以用户为中心的设计时必须考虑。

Legal and ethical pressure to provide for access by all persons suggests that mobile device interfaces need to account for brand differences, cultural differences, differences in computing experience, elderly users, and users with disabilities (e.g., visual, aural, mobility). The effects of poor usability may mean that users cannot complete their tasks or will not be satisfied with the results. This suggests the importance of user-centered design activities in each of the usability areas (user interface, external accessory interface, and service interface). Accessibility is an important design issue and must be considered when user-centered design is applied.

为了满足利益相关者的可用性期望,移动应用程序开发人员应尝试回答以下问题,以评估设备的开箱即用准备情况:

In trying to meet stakeholder usability expectations, MobileApp developers should attempt to answer these questions to assess the out-of-the-box readiness of the device:

  • 跨应用程序的用户界面是否一致?

  • Is the user interface consistent across applications?

  • 该设备是否可以与不同的网络服务互操作?

  • Is the device interoperable with different network services?

  • 该设备在目标市场领域的利益相关者价值观9方面是否可以接受?

  • Is the device acceptable in terms of stakeholder values9 in the target market area?

Eisenstein [Eis01] 声称使用抽象的、平台中立的模型来描述用户界面极大地促进了为移动设备开发一致的、可用的多平台用户界面。三个模型尤其有用。平台模型描述了每个要支持的平台所施加的约束。表示模型描述了用户界面的外观。任务模型是用户为实现其任务目标而需要执行的任务的结构化表示。在最好的情况下,基于模型的设计(第9章)涉及创建包含模型的数据库,并具有自动为多个设备生成用户界面的工具支持。利用基于模型的设计技术还可以帮助设计人员识别和适应移动计算中存在的独特环境和环境变化。如果没有用户界面的抽象描述,移动用户界面的开发可能容易出错且耗时。第271页

Eisenstein [Eis01] claims that the use of abstract, platform-neutral models to describe a user interface greatly facilitates the development of consistent, usable multiplatform user interfaces for mobile devices. Three models in particular are useful. A platform model describes the constraints imposed by each platform to be supported. A presentation model describes the appearance of the user interface. The task model is a structured representation of the tasks a user needs to perform to meet her task goals. In the best case, model-based design (Chapter 9) involves the creation of databases that contain the models and has tool support for generating user interfaces for multiple devices automatically. Utilizing model-based design techniques can also help designers recognize and accommodate the unique contexts and context changes that are present in mobile computing. Without an abstract description of a user interface, the development of mobile user interfaces can be error prone and time consuming.Page 271

13.2.2 经验教训

13.2.2 Lessons Learned

de Sá 和 Carriço [Des08] 认为开发传统软件和开发移动应用程序之间存在重要区别。软件工程师不能继续使用他们已经使用过的相同传统技术并期望它们能够成功。他们提出了三种设计移动应用程序的方法:

de Sá and Carriço [Des08] contend that there are important differences between developing conventional software and developing mobile applications. Software engineers cannot continue to use the same conventional techniques they have used and expect them to be successful. They suggest three approaches for the design of mobile applications:

使用场景。如第 12 章所述,使用场景必须考虑上下文变量(位置、用户和设备)以及上下文场景之间的转换(例如,用户从卧室移动到厨房或从手写笔切换到手指)。de Sá 和 Carriço 确定了一组在开发用户场景时应考虑的场景变量类型——位置和设置、运动和姿势、设备和使用情况、工作负载和干扰、用户偏好。

Usage Scenarios. Described in Chapter 12, usage scenarios must consider context variables (location, user, and device) and transitions between contextual scenarios (e.g., user moves from bedroom to kitchen or switches from stylus to a finger). de Sá and Carriço have identified a set of scenario-variable types that should be considered in developing the user scenarios—locations and settings, movement and posture, devices and usages, workloads and distractions, user preferences.

第272页民族志观察。10这是一种广泛使用的方法,用于收集正在设计的软件产品的代表性用户的信息。当用户改变环境时,观察他们通常很困难,因为观察者必须长时间跟踪用户,这可能会引起隐私问题。11一个复杂的因素是,用户在私人环境中完成任务的方式似乎与在社交环境中不同。可能需要观察相同的用户在多个上下文中执行任务,同时监视转换,并记录用户对更改的反应。

Page 272Ethnographic Observation.10 This is a widely used method for gathering information about representative users of a software product as it is being designed. It is often difficult to observe users as they change contexts, because the observer must follow users for long periods of time, something that could raise privacy concerns.11 A complicating factor is that users seem to complete tasks differently in private settings than in social settings. The same users may need to be observed performing tasks in multiple contexts while monitoring transitions, as well as recording user reactions to the changes.

低保真纸质原型(例如卡片或便利贴)。这是用户界面设计中一种经济有效的可用性评估方法,可以在进行任何编程之前使用。重要的是这些原型的尺寸和重量相似,并且允许它们在各种情况下使用。同样重要的是,草图或文字显示的尺寸要真实,并且最终产品必须具有高质量。必须设计用户界面小部件(例如按钮或滚动条)的位置和大小,以便当用户通过缩放扩展屏幕时它们不会消失。交互类型(例如,手写笔、操纵杆、触摸屏)需要在低保真原型(例如,彩色笔或图钉)中进行仿真,以检查放置和易用性。一旦布局和放置问题得到解决,就可以创建稍后的原型以在目标移动设备上运行。

Low-Fidelity Paper Prototypes (e.g., cards or Post-it notes). This is a cost-effective usability assessment approach in user interface design that can be used before any programming takes place. It is important for these prototypes to be similar in size and weight and for their use to be allowed in a variety of contexts. It is also important that the sketches or text displays be true to size and for the final product to be of high quality. Placement and size of user interface widgets (e.g., buttons or scrollbars) must be designed so that they will not disappear when users extend their screens by zooming. The interaction type (e.g., stylus, joy stick, touch screen) needs to be emulated in the low-fidelity prototype (e.g., colored pen or push pin) to check placement and ease of use. Later prototypes may then be created to run on the targeted mobile devices once the layout and placement issues have been resolved.

第273页

Page 273

13.3 移动架构

13.3 Mobile Architectures

服务计算12和云计算13使得基于创新架构设计的大规模分布式应用程序能够快速开发[Yau11]。这两种计算范例使得在许多不同的移动设备(例如笔记本电脑、智能手机和平板电脑)上创建应用程序变得更容易、更经济。这两种范例允许资源外包并将信息技术管理转移给服务提供商,同时减轻资源限制对某些移动设备的影响。面向服务的架构提供了移动开发所需的架构风格(例如,REST)、 14种标准协议(例如,XML 15和SOAP 16)以及接口(例如,WSDL)17 。云计算支持对可配置计算资源(服务器、存储、应用程序和服务)的共享池进行便捷的按需网络访问。

Services computing12 and cloud computing13 enable the rapid development of large-scale distributed applications based on innovative architectural designs [Yau11]. These two computing paradigms have made it easier and more economical to create applications on many different mobile devices (e.g., laptop computers, smartphones, and tablets). These two paradigms allow resource outsourcing and transfer of information technology management to service providers while at the same time mitigating the impact of resource limitations on some mobile devices. A service-oriented architecture provides the architectural style (e.g., REST),14 standard protocols (e.g., XML15 and SOAP16), and interfaces (e.g., WSDL)17 needed for mobile development. Cloud computing enables convenient, on-demand network access to a shared pool of configurable computing resources (servers, storage, applications, and services).

服务计算使移动开发人员无需将服务源代码集成到移动设备上运行的客户端中。相反,该服务在提供商的服务器之外运行,并与通过消息传递协议使用该服务的应用程序松散耦合。服务通常提供应用程序编程接口 (API),以允许将其视为抽象黑匣子。

Service computing allows mobile developers to avoid the need to integrate service source code into the client running on a mobile device. Instead, the service runs out of the provider’s server and is loosely coupled with the applications that make use of it through messaging protocols. A service typically provides an application programming interface (API) to allow it to be treated like an abstract black box.

云计算使客户端(用户或程序)可以随时随地跨网络边界请求计算能力。云架构分为三层,每一层都可以称为服务(图13.1)。软件即服务层由第三方服务提供商托管的软件组件和应用程序组成。平台即服务层提供了一个协作开发平台,以协助地理分布的团队成员进行设计、实施和测试。基础设施即服务在云上提供虚拟计算资源(存储、处理能力、网络连接)。

Cloud computing lets the client (either a user or program) request computing capabilities as needed, across network boundaries anywhere or any time. The cloud architecture has three layers, each of which can be called as a service (Figure 13.1). The software as service layer consists of software components and applications hosted by third-party service providers. The platform as service layer provides a collaborative development platform to assist with design, implementation, and testing by geographically distributed team members. Infrastructure as a service provides virtual computing resources (storage, processing power, network connectivity) on the cloud.

移动设备可以随时随地访问云服务。身份盗窃和服务劫持的风险要求移动服务和云计算提供商采用严格的安全工程技术(第18 章)来保护其用户。

Mobile devices can access cloud services from any location at any time. The risks of identity theft and service hijacking require providers of mobile services and cloud computing to employ rigorous security engineering techniques (Chapter 18) to protect their users.

13.1 云计算

Figure 13.1 Cloud computing layers

Taivalsaari [Tai12] 指出,利用云存储可以让任何移动设备或软件功能在全球数百万台设备上轻松更新。事实上,可以虚拟化整个移动用户体验,以便所有应用程序都从云端下载。

Taivalsaari [Tai12] points out that making use of cloud storage can allow any mobile device or software features to be updated easily on millions of devices worldwide. In fact, it is possible to virtualize the entire mobile user experience so that all applications are downloaded from the cloud.

第274页

Page 274

13.4 上下文感知应用程序

13.4 Context-Aware Apps

上下文允许根据移动设备的位置和设备要提供的功能创建新应用程序。上下文还可以帮助为移动设备定制个人计算机应用程序(例如,当家庭保健工作人员到达患者家中时将患者信息下载到他携带的设备上)。

Context allows the creation of new applications based on the location of the mobile device and the functionality to be delivered by the device. Context can also help tailor personal computer applications for mobile devices (e.g., downloading patient information to a device carried by a home health care worker as he arrives at the patient’s house).

使用高度自适应的上下文界面是解决设备限制(例如屏幕尺寸和内存)的好方法。为了促进上下文感知的用户交互的发展,需要相应的软件架构的支持。

Using highly adaptive, contextual interfaces is a good way to deal with device limitations (e.g., screen size and memory). To facilitate the development of context-aware user interaction requires the support of corresponding software architectures.

在上下文感知应用程序的早期讨论中,Rodden [Rod98] 指出,移动计算通过提供允许设备了解其位置、时间和周围其他对象的功能来融合现实世界和虚拟世界。该设备可以像警报传感器一样位于固定位置,嵌入自主设备中,也可以由人类随身携带。由于设备可以设计为供个人、团体或公众使用,因此它必须检测用户的存在和身份,以及与该用户相关或允许的上下文属性(即使该用户是另一个设备)。

In an early discussion of context-aware applications, Rodden [Rod98] points out that mobile computing merges the real and virtual world by providing functionality that allows a device to be aware of its location, time, and other objects in its surroundings. The device could be in a fixed location like an alarm sensor, embedded in an autonomous device, or be carried around by a human. Because the device can be designed to be used by individuals, groups, or the public, it must detect the presence and identity of the user, as well as the attributes of the context that are relevant or permitted for that user (even if the user is another device).

为了实现上下文感知,移动系统必须在存在来自各种异构源的不确定且快速变化的数据的情况下生成可靠的信息。由于噪声、校准错误、磨损和天气等问题,通过组合多个传感器的数据来提取相关上下文信息具有挑战性。基于事件的通信优于上下文感知应用程序中高抽象级别数据的连续流的管理[Kor03]。

To achieve context awareness, mobile systems must produce reliable information in the presence of uncertain and rapidly changing data from a variety of heterogeneous sources. Extracting relevant context information by combing data from several sensors proves challenging because of problems with noise, miscalibration, wear and tear, and weather. Event-based communication is preferable to the management of continuous streams of high-abstraction-level data in context-aware applications [Kor03].

第275页在无处不在的计算环境中,多个用户使用各种不同的设备。设备的配置应该足够灵活,能够根据移动工作实践的需求频繁变化。对于软件基础设施来说,支持不同风格的交互(例如手势、语音和笔)并将它们存储在可以轻松共享的抽象中非常重要。

Page 275In ubiquitous computing environments, multiple users work with a wide range of different devices. The configuration of the devices should be flexible enough to change frequently because of the demands of mobile work practices. It is important for the software infrastructure to support different styles of interaction (e.g., gestures, voice, and pen) and store them in abstractions that can be shared easily.

有时,一个用户可能希望同时使用多个设备在同一产品上工作(例如,使用触摸屏设备来编辑文档图像,使用个人键盘来编辑文档文本)。集成并非始终连接到网络且具有各种设备限制的移动设备具有挑战性[Tan01]。联网的多人游戏必须通过在每个设备上存储游戏状态并在其他游戏玩家的设备之间实时共享变化信息来处理这些问题。

There are times when one user may desire to work with more than one device simultaneously on the same product (e.g., use a touch-screen device to edit a document image and a personal keyboard to edit document text). It is challenging to integrate mobile devices that are not always connected to the network and have a variety of device constraints [Tan01]. Networked, multiplayer games have had to deal with these problems by storing the game state on each device and sharing change information among other game players’ devices in real time.

13.5 网页设计金字塔

13.5 Web Design Pyramid

Web 工程背景下的设计是什么?这个简单的问题比人们想象的更难回答。Pressman 和 Lowe [Pre08] 讨论了这个问题,他们写道:

What is design in the context of Web engineering? This simple question is more difficult to answer than one might believe. Pressman and Lowe [Pre08] discuss this when they write:

创建有效的设计通常需要多种技能。有时,对于小型项目,单个开发人员可能需要具备多种技能。对于较大的项目,利用专家的专业知识可能是明智和/或可行的:Web 工程师、图形设计师、内容开发人员、程序员、数据库专家、信息架构师、网络工程师、安全专家和测试人员。利用这些不同的技能可以创建一个模型,可以在生成内容和代码、进行测试以及最终用户大量参与之前评估质量并进行改进。如果分析是建立 WebApp 质量的地方,那么设计就是真正嵌入质量的地方。

The creation of an effective design will typically require a diverse set of skills. Sometimes, for small projects, a single developer may need to be multi-skilled. For larger projects, it may be advisable and/or feasible to draw on the expertise of specialists: Web engineers, graphic designers, content developers, programmers, database specialists, information architects, network engineers, security experts, and testers. Drawing on these diverse skills allows the creation of a model that can be assessed for quality and improved before content and code are generated, tests are conducted, and end-users become involved in large numbers. If analysis is where WebApp quality is established, then design is where the quality is truly embedded.

设计技能的适当组合将根据 Web 应用程序的性质而有所不同。图 13.2描述了 Web 应用程序的设计金字塔。金字塔的每一层都代表一个设计操作,将在下面的部分中进行描述。

The appropriate mix of design skills will vary depending upon the nature of the WebApp. Figure 13.2 depicts a design pyramid for WebApps. Each level of the pyramid represents a design action that is described in the sections that follow.

图13.2 Web 应用程序 的设计金字塔

Figure 13.2 A design pyramid for WebApps

13.5.1 Web应用程序界面设计

13.5.1 WebApp Interface Design

当用户与基于计算机的系统交互时,应用一组基本原则和压倒性的设计指南。这些已在第 12 章中讨论。18尽管 Web 应用程序带来了一些特殊的用户界面设计挑战,但基本原则和指南是适用的。

When a user interacts with a computer-based system, a set of fundamental principles and overriding design guidelines apply. These have been discussed in Chapter 12.18 Although WebApps present a few special user interface design challenges, the basic principles and guidelines are applicable.

WebApp 界面设计的挑战之一是用户入口点的不确定性。也就是说,用户可以在“主页”位置(例如,主页)进入WebApp或者可以链接到WebApp架构的某个较低级别。在某些情况下,Web 应用程序可以设计为将用户重新路由到主位置,但如果这是不可取的,则 Web 应用程序设计必须提供伴随所有内容对象的界面导航功能,并且无论用户如何输入内容都可用。系统。

One of the challenges of interface design for WebApps is the indeterminate nature of the user’s entry point. That is, the user may enter the WebApp at a “home” location (e.g., the home page) or may be linked into some lower level of the WebApp architecture. In some cases, the WebApp can be designed in a way that reroutes the user to a home location, but if this is undesirable, the WebApp design must provide interface navigation features that accompany all content objects and are available regardless of how the user enters the system.

第276页WebApp 界面的目标是:(1) 建立一个一致的窗口来了解界面提供的内容和功能,(2) 引导用户完成与 WebApp 的一系列交互,以及 (3) 组织导航选项和用户可用的内容。为了实现一致的界面,您应该首先使用视觉设计(第 12.1 节)来建立一致的“外观”。这包含许多特征,但必须强调导航机制的布局和形式。为了指导用户交互,您可以利用适当的隐喻19,使用户能够直观地理解界面。要实现导航选项,您可以选择在网页上一致定位的导航菜单、以用户能够识别图标是导航元素的方式表示的图形图标和/或提供指向内容对象的链接的图形图像或Web 应用程序功能。值得注意的是,应该在内容层次结构的每一层提供一个或多个导航机制。

Page 276The objectives of a WebApp interface are to: (1) establish a consistent window into the content and functionality provided by the interface, (2) guide the user through a series of interactions with the WebApp, and (3) organize the navigation options and content available to the user. To achieve a consistent interface, you should first use visual design (Section 12.1) to establish a coherent “look.” This encompasses many characteristics but must emphasize the layout and form of navigation mechanisms. To guide user interaction, you may draw on an appropriate metaphor19 that enables the user to gain an intuitive understanding of the interface. To implement navigation options, you can select navigation menus positioned consistently on Web pages, graphic icons represented in a manner that enable a user to recognize that the icon is a navigation element, and/or graphic images that provide a link to a content object or WebApp functionality. It is important to note that one or more of these navigation mechanisms should be provided at every level of the content hierarchy.

每个网页都有有限的“空间”,可用于支持非功能性美观、导航功能、信息内容和用户导向的功能。该房地产的开发是在美学设计期间规划的。第277页

Every Web page has a limited amount of “real estate” that can be used to support nonfunctional aesthetics, navigation features, informational content, and user-directed functionality. The development of this real estate is planned during aesthetic design.Page 277

13.5.2 美学设计

13.5.2 Aesthetic Design

美学设计,也称为视觉设计或图形设计,是一种补充 WebApp 设计技术方面的艺术努力。我们在第 12.1.4 节中讨论了视觉设计。页面布局是美学设计的一个方面,可以影响 Web 应用程序的实用性(和可用性)。

Aesthetic design, also called visual design or graphic design, is an artistic endeavor that complements the technical aspects of WebApp design. We discussed visual design in Section 12.1.4. Page layout is one aspect of aesthetic design that can affect the usefulness (and usability) of a WebApp.

设计网页布局时没有绝对的规则。然而,一些总体布局指南值得考虑:

There are no absolute rules when a Web page layout is designed. However, a number of general layout guidelines are worth considering:

  • 不要害怕开放空间。不建议将网页的每一平方英寸都塞满信息。由此产生的混乱使用户难以识别所需的信息或功能,并造成不悦目的视觉混乱。

  • Don’t be afraid of open space. It is inadvisable to pack every square inch of a Web page with information. The resulting clutter makes it difficult for the user to identify needed information or features and create visual chaos that is not pleasing to the eye.

  • 强调内容。毕竟,这就是用户存在的原因。Nielsen [Nie00] 建议典型的网页用户应该对 80% 的内容感到满意,剩余的空间专用于导航和其他功能。

  • Emphasize content. After all, that’s the reason the user is there. Nielsen [Nie00] suggests that the typical Web page user should be 80 percent content with the remaining real estate dedicated to navigation and other features.

  • 从左上到右下组织布局元素。绝大多数用户扫描网页的方式与扫描书页的方式大致相同——从左上到右下。20如果布局元素具有特定优先级,则高优先级元素应放置在页面空间的左上部分。

  • Organize layout elements from top left to bottom right. The vast majority of users will scan a Web page in much the same way as they scan the page of a book—top left to bottom right.20 If layout elements have specific priorities, high-priority elements should be placed in the upper-left portion of the page real estate.

  • 在页面内按地理位置对导航、内容和功能进行分组。人类几乎在所有事物中寻找模式。如果网页中没有可辨别的模式,用户的挫败感可能会增加(由于不必要地搜索所需信息)。

  • Group navigation, content, and function geographically within the page. Humans look for patterns in virtually all things. If there are no discernible patterns within a Web page, user frustration is likely to increase (owing to unnecessary searching for needed information).

  • 不要用滚动条来扩展你的空间。尽管滚动通常是必要的,但大多数研究表明用户宁愿不滚动。减少页面内容或在多个页面上呈现必要的内容通常会更好。

  • Don’t extend your real estate with the scrolling bar. Although scrolling is often necessary, most studies indicate that users would prefer not to scroll. It is often better to reduce page content or to present necessary content on multiple pages.

  • 设计布局时考虑分辨率和浏览器窗口大小。设计不应在布局中定义固定大小,而应将所有布局项指定为可用空间的百分比 [Nie00]。随着不同屏幕尺寸的移动设备的使用越来越多,这个概念变得越来越重要。

  • Consider resolution and browser window size when designing layout. Rather than defining fixed sizes within a layout, the design should specify all layout items as a percentage of available space [Nie00]. With the growing use of mobile devices with different screen sizes, this concept becomes increasingly important.

13.5.3 内容设计

13.5.3 Content Design

我们在12.1.1节中介绍了内容设计。在 WebApp 设计中,内容对象与传统软件的数据对象更加一致。内容对象具有的属性包括特定于内容的信息(通常在 WebApp 需求建模期间定义)和指定为设计一部分的特定于实现的属性。

We introduced content design in Section 12.1.1. In WebApp design, a content object is more closely aligned with a data object for traditional software. A content object has attributes that include content-specific information (normally defined during WebApp requirements modeling) and implementation-specific attributes that are specified as part of design.

例如,考虑为SafeHome电子商务系统开发的分析类ProductComponent 。分析类属性表示为名为CompDescription的设计类,由五个内容对象组成:MarketingDescription、Photograph、TechDescription、SchematicVideos ,如图13.3中所示的底行阴影对象所示。内容对象中包含的信息被标记为属性。例如,照片(jpg 图像)具有属性和。description,horizontal dimension, vertical dimension,border style第278页

As an example, consider an analysis class, ProductComponent, developed for the SafeHome e-commerce system. The analysis class attribute, description, is represented as a design class named CompDescription composed of five content objects: MarketingDescription, Photograph, TechDescription, Schematic, and Videos shown as the bottom row of shaded objects noted in Figure 13.3. Information contained within the content object is noted as attributes. For example, Photograph (a jpg image) has the attributes horizontal dimension, vertical dimension, and border style.Page 278

图13.3内容对象 设计表示

Figure 13.3 Design representation of content objects

UML关联和聚合21可以用于表示内容对象之间的关系。例如,图 13.3中所示的 UML 关联表明,ProductComponent类的每个实例都使用一个CompDescriptionCompDescription由所示的五个内容对象组成。然而,显示的多重符号表明原理图视频是可选的(可能出现零次),需要一项营销描述和一项技术描述,并且使用一个或多个照片实例。

UML association and an aggregation21 may be used to represent relationships between content objects. For example, the UML association shown in Figure 13.3 indicates that one CompDescription is used for each instance of the ProductComponent class. CompDescription is composed on the five content objects shown. However, the multiplicity notation shown indicates that Schematic and Videos are optional (zero occurrences are possible), one MarketingDescription and one TechDescription are required, and one or more instances of Photograph are used.

13.5.4 架构设计

13.5.4 Architecture Design

架构设计与为 WebApp 建立的目标、要呈现的内容、将访问的用户以及已建立的导航理念紧密相关。作为架构设计师,必须识别内容架构和WebApp架构。内容架构22关注内容对象(或诸如网页的复合对象)被构造用于呈现和导航的方式。WebApp 架构解决了应用程序的构建方式,以管理用户交互、处理内部处理任务、效果导航和呈现内容。第279页

Architecture design is tied to the goals established for a WebApp, the content to be presented, the users who will visit, and the navigation philosophy that has been established. As an architectural designer, you must identify content architecture and WebApp architecture. Content architecture22 focuses on the manner in which content objects (or composite objects such as Web pages) are structured for presentation and navigation. WebApp architecture addresses the manner in which the application is structured to manage user interaction, handle internal processing tasks, effect navigation, and present content.Page 279

在大多数情况下,架构设计是与界面设计、美学设计和内容设计并行进行的。由于 WebApp 架构可能对导航有很大影响,因此在此设计操作期间做出的决策将影响导航设计期间进行的工作。

In most cases, architecture design is conducted in parallel with interface design, aesthetic design, and content design. Because the WebApp architecture may have a strong influence on navigation, the decisions made during this design action will influence work conducted during navigation design.

WebApp 架构描述了使基于 Web 的系统或应用程序能够实现其业务目标的基础架构。Jacyntho 和他的同事 [Jac02b] 通过以下方式描述了该基础设施的基本特征:

WebApp architecture describes an infrastructure that enables a Web-based system or application to achieve its business objectives. Jacyntho and his colleagues [Jac02b] describe the basic characteristics of this infrastructure in the following manner:

应用程序应使用考虑不同关注点的层来构建;特别是,应用程序数据应与页面内容(导航节点)分开,而这些内容又应与界面外观(页面)明确分开。

Applications should be built using layers in which different concerns are taken into account; in particular, application data should be separated from the page’s contents (navigation nodes) and these contents, in turn, should be clearly separated from the interface look-and-feel (pages).

作者提出了一种三层设计架构,将界面与导航和应用程序行为分离。他们认为,将界面、应用程序和导航分开可以简化实现并增强重用。

The authors suggest a three-layer design architecture that decouples the interface from navigation and from application behavior. They argue that keeping the interface, application, and navigation separate simplifies implementation and enhances reuse.

模型-视图-控制器(MVC) 架构 [Kra88] 23是一种流行的 WebApp 架构模型,它将用户界面与 WebApp 功能和信息内容解耦。模型(有时称为“模型对象”)包含所有特定于应用程序的内容和处理逻辑,包括所有内容对象、对外部数据/信息源的访问以及特定于应用程序的所有处理功能视图包含所有特定于界面的功能,并支持内容和处理逻辑的表示,包括所有内容对象、对外部数据和信息源的访问以及最终用户所需的所有处理功能。控制器管理对模型和视图的访问并协调它们之间的数据流在 Web 应用程序中,“控制器根据用户输入使用模型中的数据更新视图”[WMT02]。MVC 架构的示意图如图13.4所示。

The Model-View-Controller (MVC) architecture [Kra88]23 is a popular WebApp architectural model that decouples the user interface from the WebApp functionality and information content. The model (sometimes referred to as the “model object”) contains all application-specific content and processing logic, including all content objects, access to external data/information sources, and all processing functionality that is application specific. The view contains all interface-specific functions and enables the presentation of content and processing logic, including all content objects, access to external data and information sources, and all processing functionality required by the end user. The controller manages access to the model and the view and coordinates the flow of data between them. In a WebApp, “the view is updated by the controller with data from the model based on user input” [WMT02]. A schematic representation of the MVC architecture is shown in Figure 13.4.

图13.4 MVC 架构

Figure 13.4 The MVC architecture

参考该图,用户请求或数据由控制器处理。控制器还根据用户请求选择适用的视图对象。一旦确定了请求的类型,行为请求就会传输到模型,模型实现功能或检索适应该请求所需的内容。模型对象可以访问存储在公司数据库中、作为本地数据存储的一部分或作为独立文件的集合的数据。模型开发的数据必须通过适当的视图对象进行格式化和组织,然后从应用程序服务器传输回基于客户端的浏览器,以便在客户的机器上显示。

Referring to the figure, user requests or data are handled by the controller. The controller also selects the view object that is applicable based on the user request. Once the type of request is determined, a behavior request is transmitted to the model, which implements the functionality or retrieves the content required to accommodate the request. The model object can access data stored in a corporate database, as part of a local data store, or as a collection of independent files. The data developed by the model must be formatted and organized by the appropriate view object and then transmitted from the application server back to the client-based browser for display on the customer’s machine.

第280页在许多情况下,WebApp 架构是在要实现应用程序的开发环境的上下文中定义的。如果您有进一步的兴趣,请参阅 [Fow03],了解有关开发环境及其在 Web 应用程序体系结构设计中的作用的讨论。

Page 280In many cases, WebApp architecture is defined within the context of the development environment in which the application is to be implemented. If you have further interest, see [Fow03] for a discussion of development environments and their role in the design of Web application architectures.

13.5.5 导航设计

13.5.5 Navigation Design

一旦建立了 WebApp 体系结构并确定了体系结构的组件(页面、脚本、小程序和其他处理功能),您必须定义使用户能够访问 WebApp 内容和功能的导航路径。为了实现这一点,需要确定网站不同用户的导航语义,并定义实现导航的机制(语法)。

Once the WebApp architecture has been established and the components (pages, scripts, applets, and other processing functions) of the architecture have been identified, you must define navigation pathways that enable users to access WebApp content and functions. To accomplish this, identify the semantics of navigation for different users of the site, and define the mechanics (syntax) of achieving the navigation.

与许多 WebApp 设计操作一样,导航设计首先要考虑为每个类别的用户(参与者)开发的用户层次结构和相关用例(第 8 章)。每个参与者使用 WebApp 的方式可能有所不同,因此有不同的导航要求。此外,为每个参与者开发的用例将定义一组包含一个或多个内容对象或 WebApp 功能的类。当每个用户与 WebApp 交互时,她会遇到一系列导航语义单元(NSU)——“一组信息和相关导航结构,它们协作满足相关用户需求的子集”[Cac02]。NSU 描述了每个用例的导航要求。本质上,NSU 显示了参与者如何在内容对象或 Web 应用程序功能之间移动。

Like many WebApp design actions, navigation design begins with a consideration of the user hierarchy and related use cases (Chapter 8) developed for each category of user (actor). Each actor may use the WebApp somewhat differently and therefore have different navigation requirements. In addition, the use cases developed for each actor will define a set of classes that encompass one or more content objects or WebApp functions. As each user interacts with the WebApp, she encounters a series of navigation semantic units (NSUs)—“a set of information and related navigation structures that collaborate in the fulfillment of a subset of related user requirements” [Cac02]. An NSU describes the navigation requirements for each use case. In essence, the NSU shows how an actor moves between content objects or WebApp functions.

NSU 由一组称为导航方式(WoN) [Gna99]的导航元素组成。WoN 代表实现特定类型用户的导航目标的最佳导航路径。每个 WoN 被组织为一组通过导航链接连接的导航节点(NN)。在某些情况下,导航链接可能是另一个 NSU。因此,WebApp 的整体导航结构可以组织为 NSU 的层次结构。

An NSU is composed of a set of navigation elements called ways of navigating (WoN) [Gna99]. A WoN represents the best navigation pathway to achieve a navigational goal for a specific type of user. Each WoN is organized as a set of navigational nodes (NN) that are connected by navigational links. In some cases, a navigational link may be another NSU. Therefore, the overall navigation structure for a WebApp may be organized as a hierarchy of NSUs.

第281页为了说明 NSU 的开发,请考虑使用案例选择 SafeHome 组件:

Page 281To illustrate the development of an NSU, consider the use case Select SafeHome Components:

使用案例: 选择 SafeHome 组件

Use Case: Select SafeHome Components

WebApp 将为每个房间外部入口推荐产品组件(例如,控制面板、传感器、摄像头)和其他功能(例如,在软件中实现的基于 PC 的功能) 。如果我请求替代方案,Web 应用程序将提供它们(如果存在)。我将能够获得每个产品组件的描述和定价信息。当我选择各种组件时,Web 应用程序将创建并显示物料清单。我将能够为物料清单命名并保存以供将来参考(请参阅用例保存配置)。

The WebApp will recommend product components (e.g., control panels, sensors, cameras) and other features (e.g., PC-based functionality implemented in software) for each room and exterior entrance. If I request alternatives, the WebApp will provide them, if they exist. I will be able to get descriptive and pricing information for each product component. The WebApp will create and display a bill-of-materials as I select various components. I’ll be able to give the bill-of-materials a name and save it for future reference (see use case Save Configuration).

用例描述中带下划线的项目表示将合并到一个或多个 NSU 中的类和内容对象,这些对象将使新客户能够执行“选择SafeHome 组件”用例中描述的场景。

The underlined items in the use case description represent classes and content objects that will be incorporated into one or more NSUs that will enable a new customer to perform the scenario described in the Select SafeHome Components use case.

图 13.5描述了“选择 SafeHome 组件”用例所隐含的导航的部分语义分析。使用前面介绍的术语,该图还表示SafeHomeAssured.com Web 应用程序的一种导航 (WoN) 方式。显示重要的问题域类以及选定的内容对象(在本例中为名为ProductComponentCompDescription,类的属性的内容对象包)。这些项目是导航节点。每个箭头表示导航链接24并且用引起该链接发生的用户发起的动作来标记。

Figure 13.5 depicts a partial semantic analysis of the navigation implied by the Select SafeHome Components use case. Using the terminology introduced earlier, the figure also represents a way of navigating (WoN) for the SafeHomeAssured.com WebApp. Important problem domain classes are shown, along with selected content objects (in this case the package of content objects named CompDescription, an attribute of the ProductComponent class). These items are navigation nodes. Each of the arrows represents a navigation link24 and is labeled with the user-initiated action that causes the link to occur.

13.5创建 NSU

Figure 13.5 Creating an NSU

第282页您可以为与每个用户角色关联的每个用例创建一个 NSU。例如,SafeHomeAssured.com新客户可能有三个不同的用例,所有用例都会导致访问不同的信息和 WebApp 功能。为每个目标创建一个 NSU。

Page 282You can create an NSU for each use case associated with each user role. For example, a new customer for SafeHomeAssured.com may have three different use cases, all resulting in access to different information and WebApp functions. An NSU is created for each goal.

在导航设计的初始阶段,将对 WebApp 内容架构进行评估,以确定每个用例的一个或多个 WoN。如前所述,WoN 识别导航节点(例如,内容),然后识别支持它们之间导航的链接。然后 WoN 被组织成 NSU。

During the initial stages of navigation design, the WebApp content architecture is assessed to determine one or more WoN for each use case. As noted earlier, a WoN identifies navigation nodes (e.g., content) and then links that enable navigation between them. The WoN are then organized into NSUs.

随着设计的进行,您的下一个任务是定义导航机制。大多数网站使用以下一个或多个导航选项来实现每个 NSU:单独的导航链接、水平或垂直导航栏(列表)、选项卡或访问完整的站点地图。如果定义了站点地图,则应该可以从每个页面访问它。地图本身的组织方式应使 WebApp 信息的结构一目了然。

As design proceeds, your next task is to define the mechanics of navigation. Most websites make use of one or more of the following navigation options for implementing each NSU: individual navigation links, horizontal or vertical navigation bars (lists), tabs, or access to a complete site map. If a site map is defined, it should be accessible from every page. The map itself should be organized so that the structure of WebApp information is readily apparent.

除了选择导航机制之外,您还应该建立适当的导航约定和辅助工具。例如,图标和图形链接应该通过将边缘倾斜以使图像具有三维外观来看起来“可点击”。音频或视觉反馈应设计为向用户提供已选择导航选项的指示。对于基于文本的导航,应使用颜色来指示导航链接并提供已访问链接的指示。这些只是使导航变得用户友好的数十种设计约定中的几个。

In addition to choosing the mechanics of navigation, you should also establish appropriate navigation conventions and aids. For example, icons and graphical links should look “clickable” by beveling the edges to give the image a three-dimensional look. Audio or visual feedback should be designed to provide the user with an indication that a navigation option has been chosen. For text-based navigation, color should be used to indicate navigation links and to provide an indication of links already traveled. These are but a few of dozens of design conventions that make navigation user-friendly.

13.6 组件级设计

13.6 Component-Level Design

移动应用程序提供日益复杂的处理功能,这些功能(1)执行本地化处理以动态方式生成内容和导航功能,(2)提供适合应用程序业务领域的计算或数据处理功能,(3)提供复杂的数据库查询和访问,(4) 与外部企业系统建立数据接口。为了实现这些(以及许多其他)功能,您必须设计和构建与传统软件的软件组件在形式上相同的程序组件。

Mobile apps deliver increasingly sophisticated processing functions that (1) perform localized processing to generate content and navigation capability in a dynamic fashion, (2) provide computation or data processing capability that are appropriate for the app’s business domain, (3) provide sophisticated database query and access, and (4) establish data interfaces with external corporate systems. To achieve these (and many other) capabilities, you must design and construct program components that are identical in form to software components for traditional software.

第 11 章和12章中讨论的设计方法适用于移动组件,只需进行很少的修改(如果有的话)。实现环境、编程语言、设计模式、框架和软件可能有所不同,但总体设计方法保持不变。为了注重成本,您可以设计移动组件,使其无需修改即可在多个不同的移动平台上使用。

The design methods discussed in Chapters 11 and 12 apply to mobile components with little, if any, modification. The implementation environment, programming languages, and design patterns, frameworks, and software may vary somewhat, but the overall design approach remains the same. To be cost conscious, you can design mobile components in such a way that they can be used without modification on several different mobile platforms.

13.7 移动性和设计质量

13.7 Mobility and Design Quality

每个人对于什么才是“优秀”的移动应用程序都有自己的看法。个人观点差异很大。有些用户喜欢华丽的图形;有些用户则喜欢华丽的图形。其他人想要简单的文本。有些需要大量信息;有些则需要大量信息。其他人则希望进行简短的介绍。有些人喜欢复杂的分析工具或数据库访问;有些人喜欢复杂的分析工具或数据库访问。其他人喜欢保持简单。事实上,用户对“良好”的感知(以及由此产生的对移动应用程序的接受或拒绝)可能比任何移动应用程序质量的技术讨论更重要。移动设计质量属性实际上与 WebApp 质量特征相同。第283页

Every person has an opinion about what makes a “good” mobile app. Individual viewpoints vary widely. Some users enjoy flashy graphics; others want simple text. Some demand copious information; others desire an abbreviated presentation. Some like sophisticated analytical tools or database access; others like to keep it simple. In fact, the user’s perception of “goodness” (and the resultant acceptance or rejection of a mobile app as a consequence) might be more important than any technical discussion of mobile app quality. Mobile design quality attributes are virtually the same as WebApp quality characteristics.Page 283

但如何看待移动质量呢?必须展示哪些属性才能在最终用户眼中获得良好的效果,同时展示质量的技术特征,使您能够长期纠正、适应、增强和支持移动产品?

But how is mobile quality perceived? What attributes must be exhibited to achieve goodness in the eyes of end users and at the same time exhibit the technical characteristics of quality that will enable you to correct, adapt, enhance, and support the mobile product over the long term?

实际上,第 12 章中讨论的设计质量的所有技术特征以及第 19 章中介绍的通用质量属性都适用于移动应用程序。然而,这些通用属性中最相关的——可用性、功能、可靠性、效率和可维护性——也为评估移动系统的质量提供了有用的基础。Andreou [And05] 认为,最终用户对移动应用程序的满意度取决于同样重要的质量因素——功能、可靠性、可用性、效率和可维护性——但还增加了可移植性。

In reality, all the technical characteristics of design quality discussed in Chapter 12 and the generic quality attributes presented in Chapter 19 apply to mobile apps. However, the most relevant of these generic attributes—usability, functionality, reliability, efficiency, and maintainability—provide a useful basis for assessing the quality of mobile systems as well. Andreou [And05] suggests that end-user satisfaction with a mobile app is dictated by the same important quality factors—functionality, reliability, usability, efficiency, and maintainability—but adds portability to the list.

Olsina 和他的同事 [Ols99] 准备了一个“质量需求树”,它确定了一组技术属性——可用性、功能性、可靠性、效率和可维护性——从而产生高质量的移动产品。25 图 13.6总结了他们的工作。如果您长期设计、构建和维护移动产品,则图中指出的标准特别重要。

Olsina and his colleagues [Ols99] have prepared a “quality requirement tree” that identifies a set of technical attributes—usability, functionality, reliability, efficiency, and maintainability—that lead to high-quality mobile products.25 Figure 13.6 summarizes their work. The criteria noted in the figure are of particular interest if you design, build, and maintain mobile products over the long term.

13.6质量要求

Figure 13.6 Quality requirements tree

资料来源:Olsina、Luis、Lafuente、Guillermo 和 Rossi、Gustavo,“指定网站的质量特征和属性”,第一届网络工程软件工程研讨会国际会议记录,ACM,洛杉矶,1999 年 5 月。

Source: Olsina, Luis, Lafuente, Guillermo and Rossi, Gustavo, “Specifying Quality Characteristics and Attributes for Web Sites,” Proceedings of the 1st International Conference on Software Engineering Workshop on Web Engineering, ACM, Los Angeles, May 1999.

第284页Offutt [Off02]通过添加以下属性扩展了图 13.6中提到的五个主要质量属性:

Page 284Offutt [Off02] extends the five major quality attributes noted in Figure 13.6 by adding the following attributes:

  • 安全。移动产品已与重要的企业和政府数据库高度集成。电子商务应用程序提取并存储敏感的客户信息。由于这些和许多其他原因,移动安全在许多情况下至关重要。安全的关键措施是移动应用程序及其服务器环境拒绝未经授权的访问和/或阻止彻底恶意攻击的能力。安全工程将在第 18 章中讨论。有关 WebApp 和移动应用程序安全性的更多信息,请参阅 [Web13]、[Pri10]、[Vac06] 和 [Kiz05]。

  • Security. Mobile products have become heavily integrated with critical corporate and government databases. E-commerce applications extract and then store sensitive customer information. For these and many other reasons, mobile security is paramount in many situations. The key measure of security is the ability of the mobile app and its server environment to rebuff unauthorized access and/or thwart an outright malevolent attack. Security engineering is discussed in Chapter 18. For additional information on WebApp and mobile app security, see [Web13], [Pri10], [Vac06], and [Kiz05].

  • 可用性。如果没有,再好的移动产品也无法满足用户的需求。从技术意义上来说,可用性是衡量基于 Web 的移动资源可供使用的时间百分比的指标。但 Offutt [Off02] 建议,“使用仅在一种浏览器或一种平台上可用的功能”会使具有不同浏览器或平台配置的用户无法使用移动产品。用户总是会去其他地方。

  • Availability. Even the best mobile product will not meet users’ needs if it is unavailable. In a technical sense, availability is the measure of the percentage of time that a Web-based mobile resource is available for use. But Offutt [Off02] suggests that “using features available on only one browser or one platform” makes the mobile product unavailable to those with a different browser or platform configuration. The user will invariably go elsewhere.

  • 可扩展性。移动产品及其服务器环境是否可以扩展以处理 100、1,000、10,000 或 100,000 个用户?应用程序及其连接的系统是否会处理音量的显着变化,或者响应能力是否会急剧下降(或完全停止)?设计一个能够适应成功负担(即明显更多的最终用户)并变得更加成功的移动环境非常重要。

  • Scalability. Can the mobile product and its server environment be scaled to handle 100, 1,000, 10,000, or 100,000 users? Will the app and the systems with which it is interfaced handle significant variation in volume, or will responsiveness drop dramatically (or cease altogether)? It is important to design a mobile environment that can accommodate the burden of success (i.e., significantly more end users) and become even more successful.

  • 上市时间。尽管从技术意义上来说,上市时间并不是真正的质量属性,但从业务角度来看,它是质量的衡量标准。第一个针对特定细分市场的移动产品通常会吸引不成比例的最终用户。

  • Time to Market. Although time to market is not a true quality attribute in the technical sense, it is a measure of quality from a business point of view. The first mobile product to address a specific market segment often captures a disproportionate number of end users.

  • 内容质量。数十亿个网页可供搜索信息的人使用。即使目标明确的网络搜索也会产生大量的内容。有如此多的信息源可供选择,用户如何评估移动产品中呈现的内容的质量(例如,真实性、准确性、完整性、及时性)?这是数据科学试图解决的问题的一部分。本书附录 2介绍了数据科学的基础知识。

  • Content Quality. Billions of Web pages are available for those in search of information. Even well-targeted Web searches result in an avalanche of content. With so many sources of information to choose from, how does the user assess the quality (e.g., veracity, accuracy, completeness, timeliness) of the content that is presented within a mobile product? This is part of what data science tries to address. The basics of data science are introduced in Appendix 2 of this book.

Tillman [Til00] 提出了一套有用的评估内容质量的标准:是否可以轻松确定内容的范围和深度以确保其满足用户的需求?内容作者的背景和权威是否容易识别?是否可以确定内容的货币、上次更新以及更新的内容?内容及其位置是否稳定(即它们是否会保留在引用的 URL 处)?内容可信吗?内容独特吗?也就是说,移动产品是否为使用它的人提供了一些独特的好处?内容对目标用户社区有价值吗?内容组织得好吗?索引?交通方便吗?这些问题仅代表移动产品设计发展过程中应解决的一小部分问题。第285页

Tillman [Til00] suggests a useful set of criteria for assessing the quality of content: Can the scope and depth of content be easily determined to ensure that it meets the user’s needs? Can the background and authority of the content’s authors be easily identified? Is it possible to determine the currency of the content, the last update, and what was updated? Are the content and its location stable (i.e., will they remain at the referenced URL)? Is content credible? Is content unique? That is, does the mobile product provide some unique benefit to those who use it? Is content valuable to the targeted user community? Is content well organized? Indexed? Easily accessible? These questions represent only a small sampling of the issues that should be addressed as the design of a mobile product evolves.Page 285

13.8 移动设计最佳实践

13.8 Mobility Design Best Practices

对于开发移动产品26以及为 Apple 的 iOS 27或 Google 的 Android 等特定平台开发应用程序,有一些指南。28 Schumacher [Sch09] 收集了许多最佳实践想法,并发布了一些专门适合移动应用程序和网页设计的内容。舒马赫列出的设计移动触摸屏应用程序时的一些重要考虑因素包括:

There are several guidelines for developing mobile products26 and for developing apps for specific platforms like Apple’s iOS27 or Google’s Android.28 Schumacher [Sch09] has collected many best practice ideas and has posted several specially adapted to the design of mobile applications and Web pages. Some important considerations when designing mobile touch-screen applications listed by Schumacher include:

  • 确定你的受众。编写应用程序时必须考虑到用户的期望和背景。有经验的用户希望快速完成工作。经验不足的用户在第一次使用该应用程序时会喜欢手持方式。

  • Identify your audience. The application must be written with the expectations and backgrounds of its users in mind. Experienced users want to do things quickly. Less experienced users will appreciate a handholding approach when they are first using the app.

  • 针对使用环境进行设计。重要的是要考虑用户在使用移动产品时如何与现实世界交互。在飞机上看电影需要与离开办公室之前查看天气不同的用户界面。

  • Design for context of use. It is important to consider how the user will interact with the real world while using the mobile product. Watching a movie on an airplane calls for a different user interface than checking the weather before you leave the office.

  • 简单和懒惰之间只有一线之隔。在移动设备上创建直观的用户界面比简单地删除在较大设备上运行的应用程序的用户界面中找到的功能要困难得多。用户界面应该提供使用户能够做出下一个决定的所有信息。

  • There is a fine line between simplicity and laziness. Creating an intuitive user interface on a mobile device is much harder than simply removing features found in the user interface for the application running on a larger device. The user interface should provide all the information that enables a user to make her next decision.

  • 第286页利用平台作为优势。触摸屏导航并不直观,所有新用户都必须学习。如果用户界面设计者遵守为平台设定的标准,那么这项学习任务将会变得更容易。

  • Page 286Use the platform as an advantage. Touch-screen navigation is not intuitive and must be learned by all new users. This learning task will be easier if the user interface designers adhere to standards that have been set for the platform.

  • 使滚动条和选择突出显示更加突出。滚动条通常很难在触摸设备上找到,因为它们太小了。确保菜单或图标边框足够宽,以便颜色变化能够吸引用户的注意力。使用颜色编码时,请确保前景色和背景色之间有足够的对比度,以便色盲用户能够区分它们。

  • Make scrollbars and selection highlighting more salient. Scrollbars are often hard to locate on touch devices because they are too small. Make sure that menu or icon borders are wide enough for color changes to catch the users’ attention. When color coding is used, make sure there is sufficient contrast between foreground and background colors to allow them to be distinguishable by any color-blind users.

  • 提高高级功能的可发现性。移动产品中有时会包含热键和其他快捷键,以允许有经验的用户更快地完成任务。您可以通过在用户界面中包含视觉设计线索来提高此类功能的可发现性。

  • Increase discoverability of advanced functionality. Hot keys and other shortcuts are sometimes included in mobile products to allow experienced users to complete their tasks more quickly. You can increase the discoverability of features like these by including visual design clues in the user interface.

  • 使用清晰一致的标签。小部件标签应该被所有应用程序用户识别,无论特定平台使用的标准如何。谨慎使用缩写并尽可能避免使用。

  • Use clear and consistent labels. Widget labels should be recognized by all app users, regardless of standards used by specific platforms. Use abbreviations cautiously and avoid them if possible.

  • 聪明的图标绝不应该以牺牲用户理解为代价来开发。图标通常只对其设计者有意义。用户必须能够快速了解​​其含义。很难保证图标对于所有语言和用户组都有意义。增强识别度的一个好策略是在新颖的图标下方添加文本标签。

  • Clever icons should never be developed at the expense of user understanding. Icons often only make sense to their designers. Users must be able to learn their meaning quickly. It is hard to guarantee that icons are meaningful across all languages and user groups. A good strategy to enhance recognition is to add a text label beneath a novel icon.

  • 支持用户对个性化的期望。移动设备用户希望能够对一切进行个性化设置。至少,开发人员应该尝试允许用户设置他们的位置(或自动检测)并选择该位置可能可用的内容选项。向用户表明哪些功能可以个性化以及用户如何对其进行个性化非常重要。

  • Support user expectations for personalization. Mobile device users expect to be able to personalize everything. At the very least, developers should try to allow users to set their location (or detect it automatically) and select content options that may be available at that location. It is important to indicate to users what features can be personalized and how users can personalize them.

  • 长滚动表单胜过移动设备上的多个屏幕。有经验的移动设备用户希望所有信息都在一个输入屏幕上,即使这需要滚动。新手用户通常很快就会变得有经验,并且会厌倦多个输入屏幕。

  • Long scrolling forms trump multiple screens on mobile devices. Experienced mobile device users want all information on a single input screen even if this requires scrolling. Novice users often become experienced quickly and will grow tired of multiple input screens.

为多个设备平台开发本机应用程序可能既昂贵又耗时。通过使用 Web 开发人员熟悉的技术(例如 JavaScript、CSS 和 HTML)来创建可使用移动设备上的 Web 浏览器访问的移动产品,可以降低开发成本。

Developing native applications for multiple device platforms can be costly and time consuming. Development costs can be reduced by using technologies familiar to Web developers (e.g., JavaScript, CSS, and HTML) to create mobile products that will be accessed using a Web browser on a mobile device.

无法保证桌面程序或 Web 应用程序可以轻松地适应作为移动产品的实施。然而,许多用于创建桌面计算机应用程序的敏捷软件工程实践(第 3 章)可用于创建独立应用程序或移动客户端软件,并且许多用于创建高质量 WebApps 的实践适用于 Web 服务的创建用于移动产品。

There are no guarantees that a desktop program or a WebApp can be easily adapted for implementation as a mobile product. However, many of the agile software engineering practices (Chapter 3) used to create desktop computer applications can be used to create stand-alone apps or mobile client software, and many of the practices used to create quality WebApps apply to the creation of Web services used by mobile products.

最重要的架构设计决策通常是构建瘦客户端还是胖客户端。模型-视图-控制器(MVC)架构(第13.3节)通常用于移动产品。由于移动架构对导航有很大影响,因此在此设计操作期间做出的决策将影响导航设计期间进行的工作。架构设计必须考虑设备资源(存储、处理器速度和网络连接)。设计应包括可发现服务和可移动设备的规定。第287页

The most important architectural design decision is often whether to build a thin or fat client. The model-view-controller (MVC) architecture (Section 13.3) is commonly used in mobile products. Because the mobile architecture has a strong influence on navigation, the decisions made during this design action will influence work conducted during navigation design. The architectural design must take device resources into account (storage, processor speed, and network connectivity). The design should include provisions for discoverable services and movable devices.Page 287

可用性测试和部署测试在每个原型开发周期中进行。重点关注安全问题的代码审查应作为实施活动的一部分。这些代码审查应基于系统设计活动中识别的适当安全目标和威胁。安全测试是系统测试的常规部分(第21章)。

Usability testing and deployment testing take place during each prototype development cycle. Code reviews that focus on security issues should be included as part of the implementation activities. These code reviews should be based on the appropriate security objectives and threats identified in the system design activities. Security testing is a routine part of system testing (Chapter 21).

13.9 总结

13.9 Summary

移动产品的质量(根据功能、可靠性、可用性、效率、安全性、可维护性、可扩展性和可移植性定义)是在设计过程中引入的。一个好的移动产品应该基于以下设计目标:简单、普遍、个性化、灵活性和本地化。

The quality of a mobile product—defined in terms of functionality, reliability, usability, efficiency, security, maintainability, scalability, and portability—is introduced during design. A good mobile product should be based on the following design goals: simplicity, ubiquity, personalization, flexibility, and localization.

界面设计描述了用户界面的结构和组织,包括屏幕布局的表示、交互模式的定义以及导航机制的描述。此外,优质移动产品的界面将提升品牌特征并专注于其目标设备平台。一组核心用户故事用于删除应用程序中不必要的功能,以管理其资源需求。上下文感知设备利用可发现的服务来帮助个性化用户体验。

Interface design describes the structure and organization of the user interface and includes a representation of screen layout, a definition of the modes of interaction, and a description of navigation mechanisms. In addition, the interface for a good mobile product will promote the brand signature and focus on its targeted device platform(s). A set of core user stories is used to trim unnecessary features from the app to manage its resource requirements. Context-aware devices make use of discoverable services to help personalize the user experience.

内容设计至关重要,需要考虑移动设备的屏幕和其他限制。美学设计,也称为图形设计,描述移动产品的“外观和感觉”,包括配色方案、图形布局、图形的使用以及相关的美学决策。美观设计还必须考虑设备限制。

Content design is critically important and takes the screen and other limitations of mobile devices into account. Aesthetic design, also called graphic design, describes the “look and feel” of the mobile product and includes color schemes, graphic layout, the use of graphics, and related aesthetic decisions. Aesthetic design must also take device limitations into account.

架构设计确定了移动产品的整体超媒体结构,并包含内容架构和移动架构。确定有多少移动功能将驻留在移动设备上以及有多少将由 Web 或云服务提供是至关重要的。

Architecture design identifies the overall hypermedia structure for the mobile product and encompasses both content architecture and mobile architecture. It is critical to determine how much of the mobile functionality will reside on the mobile device and how much will be provided by Web or cloud services.

导航设计代表内容对象之间以及所有移动功能的导航流。导航语法由目标移动设备上可用的小部件定义,语义通常由移动平台确定。内容分块必须考虑间歇性服务中断和用户对快速性能的需求。

Navigation design represents the navigational flow between content objects and for all mobile functions. Navigation syntax is defined by the widgets available on the targeted mobile device(s), and the semantics are often determined by the mobile platform. Content chunking must take intermittent service interruptions and user demands for fast performance into account.

组件设计开发实现用于构建完整 MobileApp 功能的组件所需的详细处理逻辑。第 12 章中描述的设计技术可能适用于移动组件的工程。

Component design develops the detailed processing logic required to implement the components that are used to build a complete MobileApp function. The design techniques described in Chapter 12 may be applicable for the engineering of mobile components.

问题与思考点

Problems and Points to Ponder

13.1. 解释为什么决定为多种设备开发移动应用程序可能是一个成本高昂的设计决策。有没有办法减轻支持错误平台的风险?

13.1. Explain why deciding to develop a MobileApp for several devices can be a costly design decision. Is there a way to mitigate the risks of supporting the wrong platform?

13.2. 在本章中,我们列出了移动产品的许多质量属性。选择您认为最重要的三个,并提出论点来解释为什么在移动设计工作中应强调每一个。第288页

13.2. In this chapter we listed many quality attributes for mobile products. Select the three that you believe are most important, and make an argument that explains why each should be emphasized in mobile design work.Page 288

13.3。您是Project Planning Corporation的一名移动应用设计师,该公司是一家开发生产力软件的公司。您想要实现相当于数字三环活页夹的功能,允许平板电脑用户在用户定义的选项卡下组织和分类多种类型的电子文档。例如,厨房改造项目可能需要 pdf 目录、jpg 或布局图、MS Word 提案以及存储在橱柜选项卡下的 Excel 电子表格。定义后,活页夹及其选项卡内容可以存储在平板电脑或某些云存储上。该应用程序需要提供五个关键功能:活页夹和选项卡定义、从 Web 位置或设备获取数字文档、活页夹管理功能、页面显示功能以及允许将便利贴添加到任何页面的注释功能。为三环应用程序开发界面设计,并将其实现为纸质原型。

13.3. You are a MobileApp designer for Project Planning Corporation, a company that builds productivity software. You want to implement the equivalent of a digital three-ring binder that allows tablet users to organize and categorize electronic documents of several types under user-defined tabs. For example, a kitchen remodeling project might require a pdf catalog, a jpg or layout drawing, an MS Word proposal, and an Excel spreadsheet stored under a Cabinetry tab. Once defined, the binder and its tab content can be stored either on the tablet or on some cloud storage. The application needs to provide five key functions: binder and tab definition, digital document acquisition from a Web location or the device, binder management functions, page display functions, and a notes function to allow a Post-it note to be added to any page. Develop an interface design for the three-ring application, and implement it as a paper prototype.

13.4。您使用过的最美观的移动应用程序是什么?为什么?

13.4. What is the most aesthetically pleasing MobileApp you have ever used and why?

13.5。为问题 13.3中描述的三环应用程序创建用户故事。

13.5. Create user stories for the three-ring application described in Problem 13.3.

13.6。可以考虑怎样使三环应用程序成为上下文感知的移动应用程序?

13.6. What might be considered to make the three-ring application a context-aware MobileApp?

13.7。重新考虑问题 13.3中描述的ProjectPlanning三环应用程序,为第一个工作原型选择一个开发平台。讨论你为什么做出这样的选择。

13.7. Reconsidering the ProjectPlanning three-ring application described in Problem 13.3, select a development platform for the first working prototype. Discuss why you made the choice.

13.8。对 MVC 架构做一些额外的研究,并决定它是否是问题 13.3中讨论的三环的合适的 MobileApp 架构。

13.8. Do a bit of additional research on the MVC architecture and decide whether it would be an appropriate MobileApp architecture for the three-ring discussed in Problem 13.3.

13.9。描述需要添加到SafeHome移动应用程序中的三个上下文感知功能。

13.9. Describe three context-aware features that would be desirable to add to a SafeHome MobileApp.

13.10。您是 FutureLearning Corporation(一家远程学习公司)的 Web 应用程序设计师。您打算实施一个基于互联网的“学习引擎”,使您能够向学生提供课程内容。学习引擎提供了用于交付任何主题的学习内容的基本基础设施(内容设计者将准备适当的内容)。为学习引擎开发原型界面设计。

13.10. You are a WebApp designer for FutureLearning Corporation, a distance learning company. You intend to implement an Internet-based “learning engine” that will enable you to deliver course content to a student. The learning engine provides the basic infrastructure for delivering learning content on any subject (content designers will prepare appropriate content). Develop a prototype interface design for the learning engine.

1可参见 http://www.devx.com/SpecialReports/Article/376​​93。

1 Available at http://www.devx.com/SpecialReports/Article/37693.

2 游牧网络与移动设备或服务器的连接不断变化。

2 Nomadic networks have changing connections to mobile devices or servers.

3 https://developer.apple.com/appstore/guidelines.html。

3 https://developer.apple.com/appstore/guidelines.html.

4 http://developer.android.com/distribute/googleplay/publish/preparing.html。

4 http://developer.android.com/distribute/googleplay/publish/preparing.html.

5 http://msdn.microsoft.com/en-us/library/ff941089%28v=vs.92%29.aspx。

5 http://msdn.microsoft.com/en-us/library/ff941089%28v=vs.92%29.aspx.

6 https://developer.amazon.com/apps-and-games/app-submission/android。

6 https://developer.amazon.com/apps-and-games/app-submission/android.

7在汽车环境中使用时,智能设备应能够限制对可能分散驾驶员注意力的服务的访问,并允许在车辆行驶时进行免提操作 [Bos11]。

7 When used in an automotive setting, smart devices should be able to restrict access to services that may distract the driver and allow hands-free operation when a vehicle is moving [Bos11].

8这些攻击涉及第三方拦截两个可信来源之间的通信并冒充其中一方或双方。

8 These attacks involve a third party intercepting communications between two trusted sources and impersonating one or both of the parties.

9品牌、伦理偏好、道德偏好、认知信仰。

9 Brand, ethical preferences, moral preferences, cognitive beliefs.

10 民族志观察是一种通过观察用户工作环境来确定用户任务性质的方法。

10 Ethnographic observation is a means determining the nature of user tasks by watching users in their work environment.

11当无法直接观察时,要求用户填写匿名调查问卷可能就足够了。

11 Asking users to fill out anonymous questionnaires may have to suffice when direct observation is not possible.

12 服务计算侧重于架构设计,并通过服务发现和组合来支持应用程序开发。

12 Services computing focuses on architectural design and enables application development through service discovery and composition.

13 云计算侧重于通过灵活、可扩展的资源虚拟化和负载平衡向用户有效提供服务。

13 Cloud computing focuses on the effective delivery of services to users through flexible and scalable resource virtualization and loading balancing.

14 表示状态转移描述了一种网络 Web 架构风格,其中资源表示(例如网页)将客户端置于新状态。客户端使用每个资源表示来更改或传输状态。

14 Representation State Transfer describes a networked Web architectural style where the resource representation (e.g., a Web page) places the client in a new state. The client changes or transfers state with each resource representation.

15 可扩展标记语言(XML) 旨在存储和传输数据,而 HTML 旨在显示数据。

15 Extensible Markup Language (XML) is designed to store and transport data, while HTML is designed to display data.

16 简单对象访问协议是在计算机网络中实现 Web 服务时交换结构化信息的规范。

16 Simple Object Access Protocol is a specification for exchanging structured information in the implementation of Web services in computer networks.

17 Web 服务描述语言是一种基于 XML 的语言,用于描述 Web 服务以及如何访问它们。

17 Web Services Description Language is an XML-based language for describing Web services and how to access them.

18第 12.1 节专门讨论用户体验设计的用户界面设计部分。如果您还没有这样做,请立即阅读。

18 Section 12.1 is dedicated to the user interface design portion of user experience design. If you have not already done so, read it at this time.

19在这种情况下,隐喻是一种可以在界面上下文中建模的表示(取自用户的现实世界体验)。一个简单的示例可能是用于控制 .mp4 文件的音量的滑块开关。

19 In this context, a metaphor is a representation (drawn from the user’s real-world experience) that can be modeled within the context of the interface. A simple example might be a slider switch that is used to control the auditory volume of an .mp4 file.

20有一些基于文化和语言的例外情况,但这条规则适用于大多数用户。

20 There are exceptions that are cultural and language based, but this rule holds for most users.

21这两种表述均在附录 1 中讨论。

21 Both of these representations are discussed in Appendix 1.

22信息架构一词也用于表示能够更好地组织、标记、导航和搜索内容对象的结构。

22 The term information architecture is also used to connote structures that lead to better organization, labeling, navigation, and searching of content objects.

23需要注意的是,MVC 实际上是为 Smalltalk 环境(参见 www.smalltalk.org)开发的一种架构设计模式,可用于任何交互式应用程序。

23 It should be noted that MVC is actually an architectural design pattern developed for the Smalltalk environment (see www.smalltalk.org) and can be used for any interactive application.

24这些有时称为导航语义链接(NSL) [Cac02]。

24 These are sometimes referred to as navigation semantic links (NSLs) [Cac02].

25这些质量属性与第 9 章和第 15 章中介绍的质量属性非常相似。这意味着质量特征对于所有软件都是通用的。

25 These quality attributes are quite similar to those presented in Chapters 9 and 15. The implication is that quality characteristics are universal for all software.

26参见http://www.w3.org/TR/mwabp/。

26 See http://www.w3.org/TR/mwabp/.

27请参阅 https://developer.apple.com/design/ human-interface-guidelines/。

27 See https://developer.apple.com/design/human-interface-guidelines/.

28请参阅http://developer.android.com/guide/components/index.html。

28 See http://developer.android.com/guide/components/index.html.

第289页

Page 289

章节

chapter

14基于模式的设计

14 Pattern-Based Design

我们每个人都遇到过设计问题,默默思考:不知道有没有人为此开发出解决方案?答案几乎总是肯定的!问题在于寻找解决方案;确保它确实适合您遇到的问题;了解可能限制解决方案应用方式的约束;最后,将建议的解决方案转化为您的设计环境。

Each of us has encountered a design problem and silently thought: I wonder if anyone has developed a solution for this? The answer is almost always yes! The problem is finding the solution; ensuring that it does, in fact, fit the problem you’ve encountered; understanding the constraints that may restrict the ways in which the solution is applied; and finally, translating the proposed solution into your design environment.

第290页但如果解决方案以某种方式编码呢?如果有一种描述问题的标准方法(以便您可以查找它),以及一种表示问题解决方案的有组织的方法,该怎么办?事实证明,软件问题已使用标准化模板进行了编码和描述,并提出了解决方案(以及约束)。这种描述问题及其解决方案的编码方法称为设计模式,允许软件工程社区以可重用的方式捕获设计知识。

Page 290But what if the solution were codified in some manner? What if there was a standard way of describing a problem (so you could look it up), and an organized method for representing the solution to the problem? It turns out that software problems have been codified and described using a standardized template, and solutions to them (along with constraints) have been proposed. Called design patterns, this codified method for describing problems and their solution allows the software engineering community to capture design knowledge in a way that enables it to be reused.

软件模式的早期历史不是始于计算机科学家,而是始于建筑建筑师 Christopher Alexander,他认识到每当设计建筑物时都会遇到一系列反复出现的问题。他将这些重复出现的问题及其解决方案描述为模式,并以以下方式描述它们[Ale77]:“每种模式都描述了在我们的环境中重复出现的问题,然后以这样的方式描述了该问题解决方案的核心:可以使用该解决方案一百万次,而无需以同样的方式重复两次。” Alexander 的想法首先通过 Gamma [Gam95]、Buschmann [Bus07] 和他们的许多同事的书籍转化为软件世界。1如今,存在数十个模式存储库,基于模式的设计可以应用于许多不同的应用领域。

The early history of software patterns begins not with a computer scientist but a building architect, Christopher Alexander, who recognized that a recurring set of problems was encountered whenever a building was designed. He characterized these recurring problems and their solutions as patterns, describing them in the following manner [Ale77]: “Each pattern describes a problem that occurs repeatedly in our environment and then describes the core of the solution to that problem in such a way that you can use the solution a million times over without ever doing it the same way twice.” Alexander’s ideas were first translated into the software world in books by Gamma [Gam95], Buschmann [Bus07], and their many colleagues.1 Today, dozens of pattern repositories exist, and pattern-based design can be applied in many different application domains.

14.1 设计模式

14.1 Design Patterns

设计模式可以被描述为“由三部分组成的规则,表达特定上下文、问题和解决方案之间的关系”[Ale79]。对于软件设计,上下文允许读者了解问题所在的环境以及在该环境中什么解决方案可能是合适的。一组要求(包括限制和约束)充当一个力量系统,影响如何在其上下文中解释问题以及如何有效应用解决方案。

A design pattern can be characterized as “a three-part rule which expresses a relation between a certain context, a problem, and a solution” [Ale79]. For software design, context allows the reader to understand the environment in which the problem resides and what solution might be appropriate within that environment. A set of requirements, including limitations and constraints, acts as a system of forces that influences how the problem can be interpreted within its context and how the solution can be effectively applied.

可以合理地认为,大多数问题都有多种解决方案,但只有适合现有问题的解决方案才是有效的。正是这种力量系统促使设计师选择特定的解决方案。目的是提供一种最能满足力量系统的解决方案,即使这些力量是矛盾的。最后,每个解决方案都会产生可能对软件其他方面产生影响的后果,并且它们本身可能成为更大系统中需要解决的其他问题的力量系统的一部分。

It is reasonable to argue that most problems have multiple solutions, but that a solution is effective only if it is appropriate within the context of the existing problem. It is the system of forces that causes a designer to choose a specific solution. The intent is to provide a solution that best satisfies the system of forces, even when these forces are contradictory. Finally, every solution has consequences that may have an impact on other aspects of the software and may themselves become part of the system of forces for other problems to be solved within the larger system.

有效的设计模式:(1) 捕获有界问题的特定解决方案,(2) 提供已在实践中证明的解决方案,(3) 确定解决不明显问题的方法,(4) 确定关系(s) 设计与其他建筑元素之间的平衡,以及 (5) 其方法和实用性是优雅的。

An effective design pattern: (1) captures a specific solution to a bounded problem, (2) provides a solution that has been proven in practice, (3) identifies an approach to a problem that is not obvious, (4) identifies the relationship(s) between the design and other architectural elements, and (5) is elegant in its approach and its utility.

第291页设计模式可以让你免于“重新发明轮子”,或者更糟糕的是,发明一个“新轮子”,这个“新轮子”稍微不圆,对于预期用途来说太小,对于滚动的地面来说太窄。如果有效地使用设计模式,一定会让您成为更好的软件设计师。

Page 291A design pattern saves you from “reinventing the wheel,” or worse, inventing a “new wheel” that is slightly out of round, too small for its intended use, and too narrow for the ground it will roll over. Design patterns, if used effectively, will invariably make you a better software designer.

14.1.1 模式种类

14.1.1 Kinds of Patterns

软件工程师对设计模式感兴趣(并感兴趣)的原因之一是人类天生擅长模式识别。如果我们不这样做,我们就会被冻结在空间和时间中——无法从经验中学习,不愿意冒险前进,因为我们无法识别可能导致高风险的情况,对一个似乎没有规律的世界感到精神错乱或逻辑一致性。幸运的是,这一切都没有发生,因为我们确实认识到生活中几乎各个方面的模式。

One of the reasons that software engineers are interested in (and intrigued by) design patterns is that human beings are inherently good at pattern recognition. If we weren’t, we’d be frozen in space and time—unable to learn from experience, unwilling to venture forward because of our inability to recognize situations that might lead to high risk, unhinged by a world that seems to have no regularity or logical consistency. Luckily, none of this occurs because we do recognize patterns in virtually every aspect of our lives.

在现实世界中,我们认识到的模式是通过一生的经验习得的。我们立即认出它们,并从本质上理解它们的含义以及如何使用它们。其中一些模式使我们能够深入了解反复出现的现象。例如,您在州际公路下班回家的路上,导航系统(或汽车收音机)通知您相反方向的州际公路上发生了严重事故。您距离事故发生地还有 4 英里,但您已经开始看到交通速度变慢,认识到了一种我们称之为“橡胶颈缩”的模式。车道上朝您方向行驶的人们看到事故后会放慢速度,以便更好地了解高速公路对面发生的情况。RubberNecking模式产生了非常可预测的结果(交通拥堵),但它只不过描述了一种现象用模式术语来说,它可能被称为非生成模式,因为它描述了上下文和问题,但它没有提供任何明确的解决方案。

In the real world, the patterns we recognize are learned over a lifetime of experience. We recognize them instantly and inherently understand what they mean and how they might be used. Some of these patterns provide us with insight into recurring phenomenon. For example, you’re on your way home from work on the interstate when your navigation system (or car radio) informs you that a serious accident has occurred on the interstate in the opposing direction. You’re 4 miles from the accident, but already you begin to see traffic slowing, recognizing a pattern that we’ll call RubberNecking. People in the travel lanes moving in your direction are slowing at the sight of the accident to get a better view of what happened on the opposite side of the highway. The RubberNecking pattern yields remarkably predictable results (a traffic jam), but it does nothing more than describe a phenomenon. In patterns jargon, it might be called a nongenerative pattern because it describes a context and a problem, but it does not provide any clear-cut solution.

当考虑软件设计模式时,我们努力识别并记录生成模式。也就是说,我们确定了一种模式,该模式描述了系统的重要且可重复的方面,并为我们提供了一种在给定上下文特有的力量系统中构建该方面的方法。在理想的环境中,生成式设计模式的集合可用于“生成”应用程序或基于计算机的系统,其架构使其能够适应变化。有时被称为生成性, “几种模式的连续应用,每种模式都封装了自己的问题和力量,展开了一个更大的解决方案,该解决方案作为较小解决方案的结果间接出现”[App00]。

When software design patterns are considered, we strive to identify and document generative patterns. That is, we identify a pattern that describes an important and repeatable aspect of a system and that provides us with a way to build that aspect within a system of forces that are unique to a given context. In an ideal setting, a collection of generative design patterns could be used to “generate” an application or computer-based system whose architecture enables it to adapt to change. Sometimes called generativity, “the successive application of several patterns, each encapsulating its own problem and forces, unfolds a larger solution which emerges indirectly as a result of the smaller solutions” [App00].

设计模式涵盖了广泛的抽象和应用。架构模式描述了使用结构方法解决的广泛的设计问题。数据模式描述了反复出现的面向数据的问题以及可用于解决这些问题的数据建模解决方案。组件模式(也称为设计模式)解决与子系统和组件的开发、它们相互通信的方式以及它们在更大的体系结构中的放置相关的问题。界面设计模式通过包含最终用户特定特征的力量系统描述常见的用户界面问题及其解决方案。WebApp 模式解决构建 WebApp 时遇到的问题集,并且通常包含刚才提到的许多其他模式类别。移动模式描述了为移动平台开发解决方案时常见的问题。在较低的抽象层次上,习语描述了如何在特定编程语言的上下文中实现软件组件的全部或部分特定算法或数据结构。不要强迫采用某种模式,即使它可以解决当前的问题。如果背景和力量是错误的,请寻找另一种模式。第292页

Design patterns span a broad spectrum of abstraction and application. Architectural patterns describe broad-based design problems that are solved using a structural approach. Data patterns describe recurring data-oriented problems and the data modeling solutions that can be used to solve them. Component patterns (also referred to as design patterns) address problems associated with the development of subsystems and components, the way they communicate with one another, and their placement within a larger architecture. Interface design patterns describe common user interface problems and their solutions with a system of forces that includes the specific characteristics of end users. WebApp patterns address a problem set that is encountered when building WebApps and often incorporates many of the other pattern categories just mentioned. Mobile patterns describe commonly encountered problems when developing solutions for mobile platforms. At a lower level of abstraction, idioms describe how to implement all or part of a specific algorithm or data structure for a software component within the context of a specific programming language. Don’t force a pattern, even if it addresses the problem at hand. If the context and forces are wrong, look for another pattern.Page 292

在他们关于设计模式的开创性著作中,Gamma 和他的同事2 [Gam95] 重点关注与面向对象设计特别相关的三种模式:创建模式、结构模式和行为模式。

In their seminal book on design patterns, Gamma and his colleagues2 [Gam95] focus on three types of patterns that are particularly relevant to object-oriented design: creational patterns, structural patterns, and behavioral patterns.

第293页创建模式专注于对象的“创建、组合和表示”,并提供使系统内对象的实例化更容易的机制,并强制“对系统内可以创建的对象的类型和数量的限制”[Maa07] 。结构模式关注与如何组织和集成类和对象以构建更大结构相关的问题和解决方案。行为模式解决与对象之间的责任分配以及对象之间的通信受到影响的方式相关的问题。

Page 293Creational patterns focus on the “creation, composition, and representation” of objects and provide mechanisms that make the instantiation of objects easier within a system and enforce “constraints on the type and number of objects that can be created within a system” [Maa07]. Structural patterns focus on problems and solutions associated with how classes and objects are organized and integrated to build a larger structure. Behavioral patterns address problems associated with the assignment of responsibility between objects and the way communication is affected between objects.

14.1.2 框架

14.1.2 Frameworks

模式本身可能不足以开发完整的设计。在某些情况下,可能需要为设计工作提供特定于实现的骨架基础设施(称为框架。框架是一种可重用的“微型架构”,它是应用其他设计模式的基础也就是说,您可以选择一个“可重用的微型架构,它为一系列软件抽象提供通用结构和行为以及上下文”。。。它指定了它们在给定域内的协作和使用”[Amb98]。

Patterns themselves may not be sufficient to develop a complete design. In some cases, it may be necessary to provide an implementation-specific skeletal infrastructure, called a framework, for design work. A framework is a reusable “mini-architecture” that serves as a foundation from which other design patterns can be applied. That is, you can select a “reusable mini-architecture that provides the generic structure and behavior for a family of software abstractions, along with a context . . . which specifies their collaboration and use within a given domain” [Amb98].

框架不是一种架构模式,而是一个具有“插头点”(也称为钩子)集合的骨架,使其能够适应特定的问题领域。插件点使您能够将特定于问题的类或功能集成到框架内。在面向对象的上下文中,框架是协作类的集合。

A framework is not an architectural pattern, but rather a skeleton with a collection of “plug points” (also called hooks and slots) that enable it to be adapted to a specific problem domain. The plug points enable you to integrate problem-specific classes or functionality within the skeleton. In an object-oriented context, a framework is a collection of cooperating classes.

Gamma 和他的同事 [Gam95] 指出模式比框架更抽象。框架可以“体现在代码中”,而模式通常是独立于代码的。框架通常包含多个单一模式,因此是比模式更大的架构元素。最后,框架驻留在特定的应用程序域中,但模式可以应用于遇到要解决的问题的任何域中。

Gamma and his colleagues [Gam95] note that patterns are more abstract than frameworks. A framework can be “embodied in code,” while a pattern is generally code independent. A framework often encompasses more than a single pattern and is therefore a larger architectural element than a pattern. Finally, a framework resides within a specific application domain, but patterns can be applied in any domain in which the problem to be addressed is encountered.

框架的设计者会争辩说,一种可重用的微型架构适用于在有限的应用领域内开发的所有软件。为了最有效,应用框架时不做任何更改。可以添加额外的设计元素,但只能通过允许设计者充实框架骨架的插入点来添加。

The designer of a framework will argue that one, reusable, mini-architecture is applicable to all software to be developed within a limited domain of application. To be most effective, frameworks are applied with no changes. Additional design elements may be added, but only via the plug points that allow the designer to flesh out the framework skeleton.

14.1.3 描述模式

14.1.3 Describing a Pattern

基于模式的设计首先是识别您打算构建的应用程序中的模式,然后继续搜索以确定其他人是否已经解决了该模式,最后以将适当的模式应用于当前的问题作为结束。这三个任务中的第二个通常是最困难的。您如何找到适合您需求的模式?

Pattern-based design begins with the recognition of patterns within the application you intend to build, continues with a search to determine whether others have addressed the pattern, and concludes with the application of an appropriate pattern to the problem at hand. The second of these three tasks is often the most difficult. How do you find patterns that fit your needs?

这个问题的答案必须依赖于模式所解决的问题、模式所在的上下文、塑造上下文的力量系统以及所提出的解决方案的有效沟通。为了明确地传达此信息,需要用于模式描述的标准表格或模板。尽管已经提出了几种不同的模式模板,但几乎所有模板都包含 Gamma 和他的同事 [Gam95] 建议的内容的主要子集。侧边栏中显示了简化的图案模板。第294页

An answer to this question must rely on effective communication of the problem the pattern addresses, the context in which the pattern resides, the system of forces that mold the context, and the solution that is proposed. To communicate this information unambiguously, a standard form or template for pattern descriptions is required. Although several different pattern templates have been proposed, almost all contain a major subset of the content suggested by Gamma and his colleagues [Gam95]. A simplified pattern template is shown in the sidebar.Page 294

设计模式的名称应谨慎选择。基于模式的设计的关键技术问题之一是当存在数百或数千个候选模式时无法找到现有模式。有意义的模式名称对搜索“正确”模式有极大的帮助。

The names of design patterns should be chosen with care. One of the key technical problems in pattern-based design is the inability to find existing patterns when hundreds or thousands of candidate patterns exist. The search for the “right” pattern is aided immeasurably by a meaningful pattern name.

模式模板提供了描述设计模式的标准化方法。每个模板条目代表可以被搜索(例如,通过数据库)的设计模式的特征,以便可以找到适当的模式。

A pattern template provides a standardized means for describing a design pattern. Each of the template entries represents characteristics of the design pattern that can be searched (e.g., via a database) so that the appropriate pattern can be found.

14.1.4 机器学习和模式发现

14.1.4 Machine Learning and Pattern Discovery

软件模式可以描述为已知问题的最佳实践解决方案。有关设计模式在软件设计中的实现位置的信息对于开发人员在创建或维护软件系统时是有用的信息。遗憾的是,由于原始开发人员的文档实践不佳,这些信息丢失了。近年来,人们对利用自动技术来识别现有软件产品中存在但未记录的新模式产生了浓厚的兴趣 [Alh12]。

Software patterns can be described as best practice solutions to known problems. Information about where design patterns have been implemented in a software design is useful information for developers to have when creating or maintaining a software system. Sadly, this information is lost due to poor documentation practices of the original developers. In recent years, there has been significant interest in making use of automatic techniques to identify new patterns present, but not documented, in existing software products [Alh12].

实现这一目标的一种方法是创建一个人工智能 (AI) 系统,能够在检查许多类似的软件系统后识别设计模式。相同的软件模式可以通过多种方式实现。机器3学习技术可以提供一种教导系统识别软件源代码中模式存在的方法。机器学习系统使用“好”和“坏”示例的特定定量标准反复检查包含软件模式的好和坏示例的训练集。这个过程一直持续到系统学会识别训练集中的大多数良好模式为止。这些训练集通常源自互联网上可用的大型开源软件系统 [Zan15]。第295页

One way to do this is to create an artificial intelligence (AI) system capable of recognizing design patterns after examining many similar software systems. The same software pattern may be implemented in many ways. Machine3 learning techniques can provide a means of teaching a system to recognize the presence of a pattern in the software source code. The machine learning system repeatedly examines a training set containing both good and bad examples of software patterns using specific quantitative criteria of “good” and “bad” examples. This process continues until the system has learned to recognize most of the good patterns in the training set. Often these training sets are derived from large open-source software systems available on the Internet [Zan15].Page 295

经过训练后,该工具可用于在训练集之外的新系统中查找软件模式。为了发挥作用,软件模式被收集在存储库中。理想情况下,可以在该存储库中搜索适用于开发人员需要解决的问题的软件模式 [Amp13]。

Once trained, the tool can be used to locate software patterns in new systems outside the training set. To be useful, the software patterns are collected in a repository. Ideally, this repository can be searched for software patterns applicable to the problems developers need to solve [Amp13].

14.2 基于模式的软件设计

14.2 Pattern-Based Software Design

任何领域最优秀的设计师都具有不可思议的能力,能够看到表征问题的模式以及可以组合起来创建解决方案的相应模式。在整个设计过程中,您应该寻找一切机会应用现有的设计模式(当它们满足设计需求时),而不是创建新的设计模式。

The best designers in any field have an uncanny ability to see patterns that characterize a problem and the corresponding patterns that can be combined to create a solution. Throughout the design process, you should look for every opportunity to apply existing design patterns (when they meet the needs of the design) rather than creating new ones.

14.2.1 上下文中基于模式的设计

14.2.1 Pattern-Based Design in Context

基于模式的设计并不是在真空中使用的。所讨论的体系结构、组件级和用户界面设计的概念和技术(第 10 章第 12 章)都与基于模式的方法结合使用。

Pattern-based design is not used in a vacuum. The concepts and techniques discussed for architectural, component-level, and user interface design (Chapter 10 through 12) are all used in conjunction with a pattern-based approach.

第 9 章中,我们注意到一组质量指南和属性是所有软件设计决策的基础。决策本身受到一组基本设计概念(例如,关注点分离、逐步细化、功能独立)的影响,这些设计概念是使用数十年来不断发展的启发式方法以及最佳实践(例如,技术、建模符号)来实现的。提议使设计更容易执行并且更有效地作为施工的基础。

In Chapter 9, we noted that a set of quality guidelines and attributes serve as the basis for all software design decisions. The decisions themselves are influenced by a set of fundamental design concepts (e.g., separation of concerns, stepwise refinement, functional independence) that are achieved using heuristics that have evolved over many decades, and best practices (e.g., techniques, modeling notation) that have been proposed to make design easier to perform and more effective as a basis for construction.

基于模式的设计在所有这一切中的作用如图 14.1所示。软件设计人员从呈现系统抽象表示的需求模型(显式或隐式)开始。需求模型描述了问题集,建立了上下文,并确定了主导力量的系统。它可能以抽象的方式暗示设计,但需求模型几乎没有明确地表示设计。

The role of pattern-based design in all of this is illustrated in Figure 14.1. A software designer begins with a requirements model (either explicit or implied) that presents an abstract representation of the system. The requirements model describes the problem set, establishes the context, and identifies the system of forces that hold sway. It may imply the design in an abstract manner, but the requirements model does little to represent the design explicitly.

图14.1上下文 中基于模式的设计

Figure 14.1 Pattern-based design in context

当您开始作为设计师的工作时,牢记质量属性(第 9 章)始终很重要。这些属性建立了一种评估软件质量的方法,但对帮助您实现它几乎没有帮助。因此,您应该应用经过验证的技术将需求模型中包含的抽象转换为更具体的形式,即软件设计。为了实现这一目标,您将使用可用于体系结构、组件级和界面设计的方法和建模工​​具。但是,只有当你面临以前尚未解决的问题、背景和力量体系时。如果解决方案已经存在,请使用它!这意味着应用基于模式的设计方法。

As you begin your work as a designer, it’s always important to keep quality attributes (Chapter 9) in mind. These attributes establish a way to assess software quality but do little to help you achieve it. Therefore, you should apply proven techniques for translating the abstractions contained in the requirements model into a more concrete form that is the software design. To accomplish this, you’ll use the methods and modeling tools available for architectural, component-level, and interface design. But, only when you’re faced with a problem, context, and system of forces that have not been solved before. If a solution already exists, use it! And that means applying a pattern-based design approach.

14.2.2 模式思考

14.2.2 Thinking in Patterns

第296页基于模式的设计意味着一种“新的思维方式”[Sha05],它首先考虑背景——大局。在评估上下文时,您可以提取必须解决的问题的层次结构。其中一些问题本质上是全局性的,而另一些问题则涉及软件的特定特性和功能。所有这些都将受到一个力量系统的影响,该系统将影响所提出的解决方案的性质。

Page 296Pattern-based design implies a “new way of thinking” [Sha05] that begins by considering context—the big picture. As context is evaluated, you extract a hierarchy of problems that must be solved. Some of these problems will be global in nature, while others will address specific features and functions of the software. All will be affected by a system of forces that will influence the nature of the solution that is proposed.

Shalloway 和 Trott [Sha05] 建议采用以下方法4,使设计人员能够以模式的方式进行思考:

Shalloway and Trott [Sha05] suggest the following approach 4 that enables a designer to think in patterns:

  1. 确保您了解大局——要构建的软件所在的上下文。需求模型应该将这一点传达给您。

  2. Be sure you understand the big picture—the context in which the software to be built resides. The requirements model should communicate this to you.

  3. 检查大局,提取该抽象级别中存在的模式。

  4. Examining the big picture, extract the patterns that are present at that level of abstraction.

  5. 从“大局”模式开始您的设计,为进一步的设计工作建立背景或框架。

  6. Begin your design with “big picture” patterns that establish a context or skeleton for further design work.

  7. “从上下文向内工作”[Sha05],寻找有助于设计解决方案的较低抽象级别的模式。

  8. “Work inward from the context” [Sha05], looking for patterns at lower levels of abstraction that contribute to the design solution.

  9. 重复步骤 1 至 4,直到完整的设计变得充实。

  10. Repeat steps 1 to 4 until the complete design is fleshed out.

  11. 通过使每种模式适应您要构建的软件的具体情况来完善设计。

  12. Refine the design by adapting each pattern to the specifics of the software you’re trying to build.

需要注意的是,模式不是独立的实体。存在于高抽象级别的设计模式总是会影响其他模式在较低抽象级别的应用方式。此外,模式经常相互协作。这意味着,当您选择一种架构模式时,它很可能会影响您选择的组件级设计模式。同样,当您选择特定的界面设计模式时,您有时被迫使用与其协作的其他模式。第297页

It’s important to note that patterns are not independent entities. Design patterns that are present at a high level of abstraction will invariably influence the ways other patterns are applied at lower levels of abstraction. In addition, patterns often collaborate with one another. The implication is that when you select an architectural pattern, it may very well influence the component-level design patterns you choose. Likewise, when you select a specific interface design pattern, you are sometimes forced to use other patterns that collaborate with it.Page 297

为了说明这一点,请考虑SafeHomeAssured.com Web 应用程序。如果从大局考虑,WebApp 必须解决如何提供有关SafeHome产品和服务的信息、如何向客户销售SafeHome产品和服务以及如何对已安装的安全系统建立基于 Internet 的监视和控制。这些基本问题中的每一个都可以进一步细化为一组子问题。

To illustrate, consider the SafeHomeAssured.com WebApp. If you consider the big picture, the WebApp must address how to provide information about SafeHome products and services, how to sell SafeHome products and services to customers, and how to establish Internet-based monitoring and control of an installed security system. Each of these fundamental problems can be further refined into a set of subproblems.

例如,如何通过互联网销售意味着一种电子商务模式,而电子商务模式本身又意味着许多较低抽象级别的模式。电子商务模式(可能是一种架构模式)意味着建立客户帐户、显示要销售的产品、选择要购买的产品等的机制。因此,如果您以模式进行思考,那么确定是否存在建立帐户的模式很重要。如果SetUpAccount可作为问题上下文的可行模式,它可以与其他模式(例如BuildInputForm、ManageFormsInputValidateFormsEntry)协作。这些模式中的每一个都描述了要解决的问题和可以应用的解决方案。

For example, How to sell via the Internet implies an e-commerce pattern that itself implies many patterns at lower levels of abstraction. The e-commerce pattern (likely, an architectural pattern) implies mechanisms for setting up a customer account, displaying the products to be sold, selecting products for purchase, and so forth. Hence, if you think in patterns, it is important to determine whether a pattern for setting up an account exists. If SetUpAccount is available as a viable pattern for the problem context, it may collaborate with other patterns such as BuildInputForm, ManageFormsInput, and ValidateFormsEntry. Each of these patterns delineates problems to be solved and solutions that may be applied.

14.2.3 设计任务

14.2.3 Design Tasks

当使用基于模式的设计理念时,将应用以下设计任务:

The following design tasks are applied when a pattern-based design philosophy is used:

  1. 检查需求模型并制定问题层次结构。通过隔离问题、背景和适用的力量系统来描述每个问题和子问题。从广泛的问题(高抽象级别)到较小的子问题(较低抽象级别)。

  2. Examine the requirements model and develop a problem hierarchy. Describe each problem and subproblem by isolating the problem, the context, and the system of forces that apply. Work from broad problems (high level of abstraction) to smaller subproblems (at lower levels of abstraction).

  3. 确定是否已为问题域开发了可靠的模式语言。模式语言包含一组模式,每个模式都使用标准化模板(第 14.1.3 节)进行描述,并相互关联以显示这些模式如何协作来解决跨应用程序域的问题。SafeHome软件团队将寻找专门为家庭安全产品开发的模式语言如果无法找到该级别的模式语言特异性,团队会将SafeHome软件问题划分为一系列通用问题域(例如,数字设备监控问题、用户界面问题、数字视频管理问题)并搜索适当的模式语言。

  4. Determine if a reliable pattern language has been developed for the problem domain. A pattern language encompasses a collection of patterns, each described using a standardized template (Section 14.1.3) and interrelated to show how these patterns collaborate to solve problems across an application domain. The SafeHome software team would look for a pattern language developed specifically for home security products. If that level of pattern language specificity could not be found, the team would partition the SafeHome software problem into a series of generic problem domains (e.g., digital device monitoring problems, user interface problems, digital video management problems) and search for appropriate pattern languages.

  5. 从一个广泛的问题开始,确定是否有一种或多种架构模式适用于该问题。如果架构模式可用,请务必检查所有协作模式。如果模式合适,则调整提出的设计解决方案并构建充分代表它的设计模型元素。例如,SafeHomeAssured.com WebApp 的一个广泛问题是通过电子商务模式解决的(第 14.2.2 节)。该模式将提出解决电子商务需求的特定架构。

  6. Beginning with a broad problem, determine whether one or more architectural patterns are available for it. If an architectural pattern is available, be certain to examine all collaborating patterns. If the pattern is appropriate, adapt the design solution proposed and build a design model element that adequately represents it. For example, a broad problem for the SafeHomeAssured.com WebApp is addressed with an e-commerce pattern (Section 14.2.2). This pattern will suggest a specific architecture for addressing e-commerce requirements.

  7. 使用为架构模式提供的协作,检查子系统或组件级问题并搜索适当的模式来解决这些问题。可能需要搜索其他模式存储库以及与架构解决方案相对应的模式列表。如果找到合适的模式,则调整所提出的设计解决方案并构建充分代表它的设计模型元素。请务必应用步骤 7。第298页

  8. Using the collaborations provided for the architectural pattern, examine subsystem or component-level problems and search for appropriate patterns to address them. It may be necessary to search through other pattern repositories as well as the list of patterns that corresponds to the architectural solution. If an appropriate pattern is found, adapt the design solution proposed and build a design model element that adequately represents it. Be certain to apply step 7.Page 298

  9. 重复步骤 2 至 4,直到解决所有广泛问题。其含义是从大局开始,逐步细化以解决越来越详细的问题。

  10. Repeat steps 2 to 4 until all broad problems have been addressed. The implication is to begin with the big picture and elaborate to solve problems at increasingly more detailed levels.

  11. 如果用户界面设计问题已被隔离(几乎总是这种情况),请在许多用户界面设计模式存储库中搜索适当的模式。按照与步骤 3 至 5 类似的方式继续操作。

  12. If user interface design problems have been isolated (this is almost always the case), search the many user interface design pattern repositories for appropriate patterns. Proceed in a manner similar to steps 3 to 5.

  13. 无论其抽象级别如何,如果模式语言和/或模式存储库或单个模式显示出希望,请将要解决的问题与现有的模式进行比较。一定要检查背景和力量,以确保该模式确实提供了适合该问题的解决方案。

  14. Regardless of its level of abstraction, if a pattern language and/or patterns repository or individual pattern shows promise, compare the problem to be solved against the existing pattern(s) presented. Be certain to examine context and forces to ensure that the pattern does, in fact, provide a solution that is amenable to the problem.

  15. 一定要改进设计,因为它是从使用设计质量标准作为指导的模式衍生而来的。

  16. Be certain to refine the design as it is derived from patterns using design quality criteria as a guide.

尽管这种设计方法从根本上来说是自上而下的,但 Gillis [Gil06] 认为“它比这更有机,比演绎更归纳,比自上而下更自下而上。” 此外,基于模式的方法必须与其他软件设计概念和技术结合使用。

Although this design approach is fundamentally top-down, Gillis [Gil06] suggests that “it’s more organic than that, more inductive than deductive, more bottom-up than top-down.” In addition, the pattern-based approach must be used in conjunction with other software design concepts and techniques.

14.2.4 构建模式组织表

14.2.4 Building a Pattern-Organizing Table

随着基于模式的设计的进行,您可能会在组织和分类来自多种模式语言和存储库的候选模式时遇到麻烦。为了帮助组织对候选模式的评估,Microsoft [Mic13b] 建议创建一个模式组织表,其一般形式如图 14.2所示。

As pattern-based design proceeds, you may encounter trouble organizing and categorizing candidate patterns from multiple pattern languages and repositories. To help organize your evaluation of candidate patterns, Microsoft [Mic13b] suggests the creation of a pattern-organizing table that takes the general form shown in Figure 14.2.

图14.2模式 组织表

Figure 14.2 A pattern-organizing table

资料来源:改编自 Microsoft,“规范架构:集成和模式”,MSDN,2004 年 5 月。

Source: Adapted from Microsoft, “Prescriptive Architecture: Integration and Patterns,” MSDN, May 2004.

模式组织表可以使用图中所示的形式实现为电子表格模型。左侧(阴影)栏中显示了按数据和内容、体系结构、组件级别和用户界面问题组织的问题陈述的缩写列表。顶行列出了四种模式类型——数据库、应用程序、实现和基础设施。候选模式的名称记录在表的单元格中。

A pattern-organizing table can be implemented as a spreadsheet model using the form shown in the figure. An abbreviated list of problem statements, organized by data and content, architecture, component level, and user interface issues, is presented in the left-hand (shaded) column. Four pattern types—database, application, implementation, and infrastructure—are listed across the top row. The names of candidate patterns are noted in the cells of the table.

为了提供组织表的条目,您将在模式语言和存储库中搜索解决单个问题陈述的模式。当找到一个或多个候选模式时,将其输入到与问题陈述相对应的行和与模式类型相对应的列中。模式的名称作为指向包含模式的完整描述的网址的 URL 的超链接来输入。

To provide entries for the organizing table, you’ll search through pattern languages and repositories for patterns that address an individual problem statement. When one or more candidate patterns is found, it is entered in the row corresponding to the problem statement and the column that corresponds to the pattern type. The name of the pattern is entered as a hyperlink to the URL of the Web address that contains a complete description of the pattern.

14.2.5 常见设计错误

14.2.5 Common Design Mistakes

使用基于模式的设计时可能会出现一些常见错误。在某些情况下,没有花费足够的时间来理解根本问题及其背景和力量,您可能会选择一种看起来正确但不适合所需解决方案的模式。一旦选择了错误的模式,您就拒绝看到自己的错误并强制适应该模式。在其他情况下,问题的力量并未被您选择的模式考虑,从而导致拟合不良或错误。有时,某个模式应用得太过字面意思,并且没有实现针对问题空间所需的调整。第299页

Several common mistakes may occur when pattern-based design is used. In some cases, not enough time has been spent to understand the underlying problem and its context and forces, and you may select a pattern that looks right but is inappropriate for the solution required. Once the wrong pattern is selected, you refuse to see your error and force-fit the pattern. In other cases, the problem has forces that are not considered by the pattern you’ve chosen, resulting in a poor or erroneous fit. Sometimes a pattern is applied too literally and the required adaptations for your problem space are not implemented.Page 299

这些错误可以避免吗?在大多数情况下,答案是肯定的。每个优秀的设计师都会寻求第二意见,并欢迎对她的作品进行审查。第 16 章中讨论的审查技术可以帮助确保您开发的基于模式的设计将为要解决的软件问题提供高质量的解决方案。

Can these mistakes be avoided? In most cases, the answer is yes. Every good designer looks for a second opinion and welcomes review of her work. The review techniques discussed in Chapter 16 can help to ensure that the pattern-based design you’ve developed will result in a high-quality solution for the software problem to be solved.

14.3 架构模式

14.3 Architectural Patterns

如果房屋建筑商决定建造一个中央大厅殖民地,则可以应用单一的建筑风格。风格的细节(例如,壁炉的数量、房屋的外观、门窗的位置)可能有很大差异,但一旦对房屋的整体架构做出决定,风格就会强加于设计。5

If a house builder decides to construct a center-hall colonial, there is a single architectural style that can be applied. The details of the style (e.g., number of fireplaces, façade of the house, placement of doors and windows) can vary considerably, but once the decision on the overall architecture of the house is made, the style is imposed on the design.5

架构模式有点不同。例如,每栋房屋(以及房屋的每种建筑风格)都采用厨房模式。厨房模式和与之协作的模式解决了与食物的存储和准备、完成这些任务所需的工具以及相对于房间内的工作流程放置这些工具的规则相关的问题。此外,该模式还可以解决与台面、照明、墙壁开关、中央岛、地板等相关的问题。显然,厨房的设计不止一种,通常由环境和力量系统决定。但每种设计都可以在厨房模式所建议的“解决方案”的背景下构思。第 300 页

Architectural patterns are a bit different. For example, every house (and every architectural style for houses) employs a Kitchen pattern. The Kitchen pattern and patterns it collaborates with address problems associated with the storage and preparation of food, the tools required to accomplish these tasks, and rules for placement of these tools relative to workflow in the room. In addition, the pattern might address problems associated with countertops, lighting, wall switches, a central island, flooring, and so on. Obviously, there is more than a single design for a kitchen, often dictated by the context and system of forces. But every design can be conceived within the context of the “solution” suggested by the Kitchen pattern.Page 300

软件架构可能有多种架构模式来解决并发、持久性和分布等问题。在特定领域中选择代表性架构模式之前,必须评估其对于应用程序和整体架构风格的适当性,以及它指定的上下文和力量系统。

A software architecture may have several architectural patterns that address issues such as concurrency, persistence, and distribution. Before a representative architectural pattern can be chosen in a specific domain, it must be assessed for its appropriateness for the application and the overall architectural style, as well as the context and system of forces that it specifies.

14.4 组件级设计模式

14.4 Component-Level Design Patterns

组件级设计模式为您提供了经过验证的解决方案,可以解决从需求模型中提取的一个或多个子问题。在许多情况下,这种类型的设计模式侧重于系统的某些功能元素。例如,SafeHomeAssured.com应用程序必须解决以下设计子问题:如何获取任何SafeHome设备的产品规格和相关信息?

Component-level design patterns provide you with proven solutions that address one or more subproblems extracted from the requirements model. In many cases, design patterns of this type focus on some functional element of a system. For example, the SafeHomeAssured.com application must address the following design subproblem: How do I get product specifications and related information for any SafeHome device?

陈述了必须解决的子问题后,您现在应该考虑影响解决方案的背景和力量系统。通过检查适当的需求模型用例,您会了解到消费者将SafeHome设备(例如安全传感器或摄像头)的规范用于提供信息。然而,当选择电子商务功能时,可以使用与规范相关的其他信息(例如,定价)。

Having stated the subproblem that must be solved, you should now consider context and the system of forces that affect the solution. Examining the appropriate requirements model use case, you learn that the consumer uses the specification for a SafeHome device (e.g., a security sensor or camera) for informational purposes. However, other information that is related to the specification (e.g., pricing) may be used when e-commerce functionality is selected.

子问题的解决涉及搜索。由于搜索是一个非常常见的问题,因此存在许多与搜索相关的模式也就不足为奇了。查看多个模式存储库,您会发现以下模式以及每个模式解决的问题:

The solution to the subproblem involves a search. Because searching is a very common problem, it should come as no surprise that there are many search-related patterns. Looking through several patterns repositories, you find the following patterns, along with the problem that each solves:

  • 高级搜索。用户必须在大量项目中找到特定项目。

  • AdvancedSearch. Users must find a specific item in a large collection of items.

  • 帮助向导。用户需要有关与网站相关的特定主题或需要在网站内查找特定页面的帮助。

  • HelpWizard. Users need help on a certain topic related to the website or when they need to find a specific page within the site.

  • 搜索区域。用户必须找到一个页面。

  • SearchArea. Users must find a page.

  • 搜索提示。用户需要知道如何控制搜索引擎。

  • SearchTips. Users need to know how to control the search engine.

  • 搜索结果。用户必须处理搜索结果列表。

  • SearchResults. Users must process a list of search results.

  • 搜索框。用户必须找到某个项目或特定信息。

  • SearchBox. Users must find an item or specific information.

对于SafeHomeAssured.com来说,产品数量不是特别多,而且每个产品的分类都比较简单,因此AdvancedSearchHelpWizard可能没有必要。同样,搜索非常简单,不需要SearchTips然而, SearchBox的描述(部分)如下:第301页

For SafeHomeAssured.com, the number of products is not particularly large, and each has a relatively simple categorization, so AdvancedSearch and HelpWizard are probably not necessary. Similarly, the search is simple enough not to require SearchTips. The description of SearchBox, however, is given (in part) as:Page 301

搜索框
改编自 www.welie.com/patterns/showPattern.php?patternID=search
问题: 用户需要查找项目或特定信息。
动机: 在组织为网页的内容对象集合中应用关键字搜索的任何情况。
语境: 用户希望直接搜索多个网页上包含的内容,而不是使用导航来获取信息或内容。任何已经有主导航的网站。用户可能想要搜索类别中的项目。用户可能想要进一步指定查询。
军队: 该网站已经有了主要的导航。用户可能想要搜索类别中的项目。用户可能希望使用简单的布尔运算符进一步指定查询。
解决方案: 提供搜索功能,包括搜索标签、关键字字段、过滤器(如果适用)和“执行”按钮。按返回键与选择执行按钮具有相同的功能。还在单独的页面中提供搜索提示和示例。该页面的链接位于搜索功能旁边。搜索词的编辑框足够大,可以容纳三个典型的用户查询(通常大约 20 个字符)。如果过滤器的数量超过 2,则使用组合框进行过滤器选择,否则使用单选按钮。
  搜索结果显示在新页面上,并带有至少包含“搜索结果”或类似内容的清晰标签。搜索功能会在页面顶部重复输入关键字,以便用户知道关键字是什么。
模式描述继续与其他条目一起,如第 14.1.3 节中所述。

该模式继续描述如何访问、呈现、匹配搜索结果等。基于此,SafeHomeAssured.com团队可以设计实现搜索所需的组件或(更有可能)获取现有的可重用组件。

The pattern goes on to describe how the search results are accessed, presented, matched, and so on. Based on this, the SafeHomeAssured.com team can design the components required to implement the search or (more likely) acquire existing reusable components.

14.5 反模式

14.5 Anti-Patterns

设计模式为您提供了经过验证的解决方案,可以解决从需求模型中提取的一个或多个问题。反模式描述了通常对软件质量产生负面影响的设计问题的常用解决方案。换句话说,它们描述了设计问题的糟糕解决方案,或者至少描述了在错误的上下文中应用设计模式的后果。反模式可以提供工具来帮助开发人员识别这些问题何时存在,并可以提供详细的计划来扭转潜在的问题原因并为这些问题实施更好的解决方案[Bro98]。当开发人员寻找重构软件产品以提高其质量的方法时,反模式可以为他们提供有价值的指导。此外,技术评审员(第 16 章)可以使用它们来发现关注的领域。

Design patterns provide you with proven solutions that address one or more problems extracted from the requirements model. Anti-patterns describe commonly used solutions to design problems that usually have negative effects on software quality. In other words, they describe bad solutions to the design problems or at the very least describe the consequence of applying a design pattern in the wrong context. Anti-patterns can provide tools to help developers recognize when these problems exist and may provide detailed plans for reversing the underlying problem causes and implementing better solutions to these problems [Bro98]. Anti-patterns can provide valuable guidance to developers when they are looking for ways to refactor software products to improve their quality. In addition, they can be used by technical reviewers (Chapter 16) to uncover area of concern.

Brown 和他的同事 [Bro98] 对模式和反模式描述进行了以下比较。设计模式通常是自下而上编写的。设计模式描述从问题的重复解决方案开始,然后添加应用该解决方案的情况的力量、症状和上下文元素。反模式是从上到下编写的。反模式描述采用反复出现的设计问题或不良的开发实践,然后列出其症状和负面后果。然后可以包括一个推荐的程序来减少反模式中记录的后果。以下示例介绍了Blob反模式。第303页

Brown and his colleagues [Bro98] make the following comparisons between pattern and anti-pattern descriptions. Design patterns are usually written from the bottom up. A design pattern description starts with a recurring solution to a problem and then adds forces, symptoms, and context elements of the situation in which the solution is to be applied. Anti-patterns are written from the top down. An anti-pattern description takes a recurring design problem, or a bad development practice, and then lists its symptoms and negative consequences. It is then possible to include a recommended procedure for reducing the consequences documented in the anti-pattern. The Blob anti-pattern is presented in the following example.Page 303

斑点

The Blob

改编自 http://antipatterns.com/briefing/sld024.htm

(Adapted from http://antipatterns.com/briefing/sld024.htm)

问题:

Problem:

具有大量属性和/或操作的单个类。

Single class with large number of attributes, operations, or both.

症状和后果:

Symptoms and Consequences:

  • 封装在单个类中的不相关属性和操作的不同集合。

  • A disparate collection of unrelated attributes and operations encapsulated in a single class.

  • 属性和操作总体上缺乏内聚性是The Blob的典型特征。

  • An overall lack of cohesiveness of the attributes and operations is typical of The Blob.

  • 具有关联的简单数据对象类的单个控制器类。

  • A single controller class with associated simple, data-object classes.

  • 单个控制器类封装了整个功能,就像过程主程序一样。

  • A single controller class encapsulates the entire functionality like a procedural main program.

  • Blob限制了在不影响其他对象功能的情况下修改系统的能力。

  • The Blob limits the ability to modify the system without affecting the functionality of other objects.

  • 对系统中其他对象的修改也可能会影响Blob 的类。

  • Modifications to other objects in the system are also likely to impact The Blob’s class.

  • Blob类通常过于复杂,无法重用和测试。

  • The Blob class is typically too complex for reuse and testing.

  • Blob类加载到内存中的成本可能很高,并且使用过多的资源。

  • The Blob class may be expensive to load into memory and uses excessive resources.

典型原因:

Typical Causes:

  • 缺乏面向对象的体系结构。

  • Lack of an object-oriented architecture.

  • 团队可能缺乏适当的抽象技能。

  • The team may be lacking appropriate abstraction skills.

  • 缺乏定义的软件架构。

  • Lack of defined software architecture.

  • 缺乏对架构设计的编程语言支持。

  • Lack of programming language support for architectural design.

  • 在迭代项目中,开发人员倾向于向现有类添加少量功能。

  • In iterative projects, developers tend to add little pieces of functionality to existing classes.

  • 在需求分析期间定义系统架构通常会导致Blob

  • Defining system architecture during requirements analysis often leads to The Blob.

解决方案:

Solution:

  • 该解决方案涉及某种形式的重构。

  • The solution involves a form of re-factoring.

  • 关键是将行为从Blob中移开。

  • The key is to move behavior away from The Blob.

  • 以降低Blob复杂性的方式将行为重新分配给其他数据对象。

  • Reallocate behavior to other data objects in ways that make The Blob less complex.

对反模式的完整讨论超出了本书的范围。接下来的侧边栏中出现了几个带有彩色和描述性名称的反模式。我们怀疑您会认识到许多反模式名称是您在学习编程时被告知要避免的开发实践。第304页

A complete discussion of anti-patterns is beyond the scope of this book. Several anti-patterns with colorful and descriptive names appear in the sidebar that follows. We suspect you will recognize many of the anti-pattern names as development practices you were told to avoid when you learned to program.Page 304

14.6 用户界面设计模式

14.6 User Interface Design Patterns

近年来,人们提出了数百种用户界面(UI)模式。大多数属于 Tidwell [Tid11] 和 vanWelie [Wel01] 所描述的 10 类模式之一。一些代表性类别(通过简单示例6进行讨论)如下:

Hundreds of user interface (UI) patterns have been proposed in recent years. Most fall within one of 10 categories of patterns as described by Tidwell [Tid11] and vanWelie [Wel01]. A few representative categories (discussed with a simple example6) follow:

整个用户界面。为整个界面的顶层结构和导航提供设计指导。

Whole UI. Provide design guidance for top-level structure and navigation throughout the entire interface.

图案: 顶级导航
简要描述;简介: 当站点或应用程序实现多个主要功能时使用。提供顶级菜单,通常与徽标或识别图形结合使用,可以直接导航到系统的任何主要功能。
细节: 主要功能(通常限于四到七个功能名称)在显示屏顶部以水平文本行列出(也可以采用垂直列格式)。每个名称都提供了相应功能或信息源的链接。通常与稍后讨论的面包屑模式一起使用。
导航元素: 每个功能/内容名称代表相应功能或内容的链接。

页面布局。解决页面(对于网站)或不同屏幕显示(对于交互式应用程序)的一般组织。第305页

Page layout. Address the general organization of pages (for websites) or distinct screen displays (for interactive applications).Page 305

图案: 卡叠
简要描述;简介: 当必须以随机顺序选择与某个特性或功能相关的多个特定子功能或内容类别时使用。提供一堆选项卡的外观,每个选项卡都可以通过单击鼠标进行选择,并且每个选项卡都代表特定的子功能或内容类别。
细节: 选项卡是一个易于理解的比喻,并且易于用户操作。每个选项卡(分隔符)的格式可能略有不同。有些可能需要输入并具有按钮或其他导航机制;其他可能仅供参考。可以与其他模式结合使用,例如下拉列表、填空等。
导航元素: 在选项卡上单击鼠标会出现相应的卡。卡内的导航功能也可能存在,但一般来说,这些功能应该启动与卡数据相关的功能,而不是导致与某些其他显示的实际链接。

电子商务。具体到网站,这些模式实现了电子商务应用程序的重复元素。

E-commerce. Specific to websites, these patterns implement recurring elements of e-commerce applications.

图案: 购物车
简要描述;简介: 提供选择购买的商品列表。
细节: 列出商品、数量、产品代码、库存情况(有货、缺货)、价格、交货信息、运费和其他相关购买信息。还提供编辑功能(例如,删除、更改数量)。
导航元素: 包含继续购物或结账的能力。

前面的每个示例模式(以及每个类别中的所有模式)也将具有完整的组件级设计,包括设计类、属性、操作和接口。如果您有进一步的兴趣,请参阅 [Cho16]、[Gas17]、[Kei18]、[Tid11]、[Hoo12] 和 [Wel01] 了解更多信息。反模式的作用及其对 UX 设计的影响可以在 [Sch15] 和 [Gra18] 中找到。

Each of the preceding example patterns (and all patterns within each category) would also have a complete component-level design, including design classes, attributes, operations, and interfaces. If you have further interest, see [Cho16], [Gas17], [Kei18], [Tid11], [Hoo12], and [Wel01] for further information. The role of anti-patterns and their effects on UX design can be found in [Sch15] and [Gra18].

14.7 移动性设计模式

14.7 Mobility Design Patterns

通过本章,您已经了解了不同类型的模式以及如何对它们进行分类。就其本质而言,移动应用程序都是关于界面的。在许多情况下,移动 UI 模式 [Mob12] 被表示为各种不同类别的应用程序的“同类最佳”屏幕图像的集合。典型的例子可能包括:

Throughout this chapter you’ve learned that there are different types of patterns and how they can be categorized. By their nature, mobile applications are all about the interface. In many cases, mobile UI patterns [Mob12] are represented as a collection of “best of breed” screen images for apps in a variety of different categories. Typical examples might include:

  • 登记屏幕。如何从特定位置签入、发表评论以及与社交网络上的朋友和关注者分享评论?第306页

  • Check-in screens. How do I check in from a specific location, make a comment, and share comments with friends and followers on a social network?Page 306

  • 地图。如何在解决其他主题的应用程序上下文中显示地图?例如,查看一家餐厅并表示其在城市中的位置。

  • Maps. How do I display a map within the context of an app that addresses some other subject? For example, review a restaurant and represent its location within a city.

  • 约夏克布丁。如何表示实时出现或由于用户操作而产生的消息或信息(来自应用程序或其他用户)?

  • Popovers. How do I represent a message or information (from the app or another user) that arises in real time or as the consequence of a user action?

  • 注册流程。如何提供一种简单的方式来登录或注册信息或功能?

  • Sign-up flows. How do I provide a simple way to sign in or register for information or functionality?

  • 自定义选项卡导航。如何以一种使用户能够选择她想要的内容对象的方式来表示各种不同的内容对象?

  • Custom tab navigation. How do I represent a variety of different content objects in a manner that enables the user to select the one she wants?

  • 邀请函。我如何通知用户他必须参与某些操作或对话?典型的示例可能包括使用对话框、工具提示或自播放视频演示。

  • Invitations. How do I inform the user that he must participate in some action or dialog? Typical examples might include making use of a dialog box, a tool tip, or a self-playing video demo.

有关移动 UI 模式的更多信息可以在 [Nei14]、[Hoo12]、[McT16]、[Abr17] 和 [Pun17] 中找到。除了 UI 模式之外,Meier 和他的同事 [Mei12] 还为移动应用程序提出了各种更通用的模式描述。

Additional information about mobile UI patterns can be found in [Nei14], [Hoo12], [McT16], [Abr17], and [Pun17]. In addition to UI patterns, Meier and his colleagues [Mei12] propose a variety of more general pattern descriptions for mobile apps.

14.8 总结

14.8 Summary

设计模式提供了一种编码机制,用于描述问题及其解决方案,使软件工程社区能够捕获设计知识以供重用。模式描述问题,指示使用户能够理解问题所在环境的上下文,并列出一个力量系统,指示如何在其上下文中解释问题以及如何应用解决方案。在软件工程工作中,我们识别并记录生成模式。这些模式描述了系统的一个重要且可重复的方面,然后为我们提供了一种在给定上下文特有的力量系统中构建该方面的方法。

Design patterns provide a codified mechanism for describing problems and their solution in a way that allows the software engineering community to capture design knowledge for reuse. A pattern describes a problem, indicates the context enabling the user to understand the environment in which the problem resides, and lists a system of forces that indicate how the problem can be interpreted within its context and how the solution can be applied. In software engineering work, we identify and document generative patterns. These patterns describe an important and repeatable aspect of a system and then provide us with a way to build that aspect within a system of forces that is unique to a given context.

架构模式描述了使用结构方法解决的广泛的设计问题。数据模式描述了反复出现的面向数据的问题以及可用于解决这些问题的数据建模解决方案。组件模式(也称为设计模式)解决与子系统和组件的开发、它们相互通信的方式以及它们在更大的体系结构中的放置相关的问题。软件反模式描述了导致创建质量低劣的软件产品的常见问题的解决方案。界面设计模式描述了常见的用户界面问题及其解决方案,其中包括最终用户的特定特征的力量系统。移动模式解决了特定于移动平台的移动界面和功能以及控制元素的独特性质。

Architectural patterns describe broad-based design problems that are solved using a structural approach. Data patterns describe recurring data-oriented problems and the data modeling solutions that can be used to solve them. Component patterns (also referred to as design patterns) address problems associated with the development of subsystems and components, the ways in which they communicate with one another, and their placement within a larger architecture. Software anti-patterns describe commonly occurring solutions to a problem that lead to the creation of software products with poor quality. Interface design patterns describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end users. Mobile patterns address the unique nature of the mobile interface and functionality and control elements that are specific to mobile platforms.

框架提供了一个基础设施,其中可以驻留模式,并且习语描述特定算法或数据结构的全部或部分的编程语言特定的实现细节。标准表格或模板用于模式描述。模式语言包含一组模式,每个模式都使用标准化模板进行描述,并相互关联以显示这些模式如何协作解决跨应用程序域的问题。第307页

A framework provides an infrastructure in which patterns may reside and idioms describe programming language–specific implementation detail for all or part of a specific algorithm or data structure. A standard form or template is used for pattern descriptions. A pattern language encompasses a collection of patterns, each described using a standardized template and interrelated to show how these patterns collaborate to solve problems across an application domain.Page 307

基于模式的设计与体系结构、组件级和用户界面设计方法结合使用。设计方法首先检查需求模型,以隔离问题、定义上下文并描述力量系统。接下来,搜索问题域的模式语言以确定是否存在已隔离问题的模式。一旦找到合适的模式,它们就被用作设计指南。

Pattern-based design is used in conjunction with architectural, component-level, and user interface design methods. The design approach begins with an examination of the requirements model to isolate problems, define context, and describe the system of forces. Next, pattern languages for the problem domain are searched to determine if patterns exist for the problems that have been isolated. Once appropriate patterns have been found, they are used as a design guide.

问题与思考点

Problems and Points to Ponder

14.1. 讨论设计模式的三个“部分”,并提供来自软件以外领域的每个部分的具体示例。

14.1. Discuss the three “parts” of a design pattern, and provide a concrete example of each from some field other than software.

14.2. 模式和反模式有什么区别?

14.2. What is the difference between a pattern and an anti-pattern?

14.3。架构模式与组件模式有何不同?

14.3. How do architectural patterns differ from component patterns?

14.4。什么是框架,它与模式有何不同?什么是习语,它与模式有何不同?

14.4. What is a framework, and how does it differ from a pattern? What is an idiom, and how does it differ from a pattern?

14.5。使用第 14.1.3 节中提供的设计模式模板,为讲师建议的模式开发完整的模式描述。

14.5. Using the design pattern template presented in Section 14.1.3, develop a complete pattern description for a pattern suggested by your instructor.

14.6。为您熟悉的运动开发一种骨骼模式语言。你可以从解决背景、力量系统以及教练和团队必须解决的广泛问题开始。您只需指定模式名称并为每个模式提供一句话描述。

14.6. Develop a skeletal pattern language for a sport with which you are familiar. You can begin by addressing the context, the system of forces, and the broad problems that a coach and team must solve. You need only specify pattern names and provide a one-sentence description for each pattern.

14.7。当克里斯托弗·亚历山大(Christopher Alexander)说“好的设计不能简单地通过将各个功能部件组合在一起来实现”时,您认为他的意思是什么?

14.7. When Christopher Alexander says, “good design cannot be achieved simply by adding together performing parts,” what do you think he means?

14.8。使用第 14.2.3 节中提到的基于模式的设计任务,为第 12.3.2 节中描述的“室内设计系统”开发骨架设计。

14.8. Using the pattern-based design tasks noted in Section 14.2.3, develop a skeletal design for the “interior design system” described in Section 12.3.2.

14.9。为问题 14.8中使用的模式构建一个模式组织表。

14.9. Build a pattern-organizing table for the patterns you used in Problem 14.8.

14.10。使用第 14.3 节中介绍的设计模式模板。

14.10. Using the design pattern template presented in Section 14.3.

1早期对软件模式的讨论确实存在,但是这两本经典书籍是对该主题的第一个一致的处理。

1 Earlier discussions of software patterns do exist, but these two classic books were the first cohesive treatments of the subject.

2 Gamma 和他的同事 [Gam95] 在模式文献中通常被称为“四人帮”(GoF)。

2 Gamma and his colleagues [Gam95] are often referred to as the “Gang of Four” (GoF) in patterns literature.

3机器学习是一种人工智能技术,它使用统计技术使系统能够从示例中学习并提高其性能,而无需明确编程。对于那些有兴趣更详细地研究这个主题的读者,请参阅 [Kub17]。

3 Machine learning is an AI technique that uses statistical techniques to allow a system to learn from examples and improve its performance without being explicitly programmed. For those readers interested in pursuing this subject in greater detail, see [Kub17].

4基于 Christopher Alexander [Ale79] 的作品。

4 Based on the work of Christopher Alexander [Ale79].

5这意味着将有一个中央门厅和走廊,房间将放置在门厅的左侧和右侧,房屋将有两层(或更多)层,房屋的卧室将在楼上,并且很快。一旦决定使用中心大厅殖民风格,这些“规则”就会被强制执行。

5 This implies that there will be a central foyer and hallway, that rooms will be placed to the left and right of the foyer, that the house will have two (or more) stories, that the bedrooms of the house will be upstairs, and so on. These “rules” are imposed once the decision is made to use the center-hall colonial style.

6此处使用缩写模式模板。完整的模式描述(以及数十种其他模式)可以在 [Tid11] 和 [Wel01] 中找到。

6 An abbreviated pattern template is used here. Full pattern descriptions (along with dozens of other patterns) can be found at [Tid11] and [Wel01].

第309页

Page 309

部分 质量与安全

PART Three Quality and Security

在《软件工程:从业者方法》的这一部分中,您将了解用于管理和控制软件质量的原理、概念和技术。这些问题将在以下章节中讨论:

In this part of Software Engineering: A Practitioner’s Approach, you’ll learn about the principles, concepts, and techniques that are applied to manage and control software quality. These questions are addressed in the chapters that follow:

  • 高质量软件的一般特征是什么?

  • What are the generic characteristics of high-quality software?

  • 我们如何审查质量,如何进行有效的审查?

  • How do we review quality, and how are effective reviews conducted?

  • 什么是软件质量保证?

  • What is software quality assurance?

  • 哪些策略适用于软件测试?

  • What strategies are applicable for software testing?

  • 使用什么方法来设计有效的测试用例?

  • What methods are used to design effective test cases?

  • 是否有现实的方法可以确保软件的正确性?

  • Are there realistic methods that will ensure that software is correct?

  • 我们如何管理和控制软件构建过程中经常发生的变更?

  • How can we manage and control changes that always occur as software is built?

  • 可以使用哪些措施和指标来评估需求和设计模型、源代码和测试用例的质量?

  • What measures and metrics can be used to assess the quality of requirements and design models, source code, and test cases?

  • 我们如何确保产品的安全问题在软件生命周期中得到解决?

  • How do we ensure the security concerns for a product are being addressed during the software life cycle?

一旦回答了这些问题,您就会做好更好的准备,以确保生产出高质量的软件。

Once these questions are answered, you’ll be better prepared to ensure that high-quality software has been produced.

第310页

Page 310

章节

chapter

15品质理念

15 Quality Concepts

随着软件越来越融入我们生活的各个方面,提高软件质量的鼓声开始认真地开始。到 20 世纪 90 年代,各大公司认识到每年有数十亿美元浪费在无法提供所承诺的特性和功能的软件上。更糟糕的是,政府和行业越来越担心重大软件故障可能会削弱重要的基础设施,造成数百亿美元的损失。到了世纪之交,《CIO 杂志》大肆宣扬这样的标题:“让我们停止每年浪费 780 亿美元”,并感叹“美国企业花费数十亿美元购买的软件却没有发挥应有的作用”[Lev01]。遗憾的是,至少一项 2014 年软件质量实践状况调查表明,维护和软件演化活动占软件开发总成本的 90% 以上 [Nan14]。由于急于发布未经充分测试的产品而导致的软件质量低下,继续困扰着软件行业。

The drumbeat for improved software quality began in earnest as software became increasingly integrated in every facet of our lives. By the 1990s, major corporations recognized that billions of dollars each year were being wasted on software that didn’t deliver the features and functionality that were promised. Worse, both government and industry became increasingly concerned that a major software fault might cripple important infrastructure, costing tens of billions more. By the turn of the century, CIO Magazine trumpeted the headline, “Let’s Stop Wasting $78 Billion a Year,” lamenting the fact that “American businesses spend billions for software that doesn’t do what it’s supposed to do” [Lev01]. Sadly, at least one survey of the state of software quality practices done in 2014 suggests that maintenance and software evolution activities make up as much as 90 percent of the total software development costs [Nan14]. Poor software quality caused by a rush to release products without adequate testing continues to plague the software industry.

第311页如今,软件质量仍然是一个问题,但谁该责怪呢?客户指责开发人员,认为草率的做法会导致低质量的软件。开发人员指责客户(和其他利益相关者),认为不合理的交付日期和持续不断的变更迫使他们在软件得到充分验证之前就交付软件。谁是对的?两者都是——这就是问题所在。在本章中,我们将软件质量视为一个概念,并研究为什么在应用软件工程实践时它值得认真考虑。

Page 311Today, software quality remains an issue, but who is to blame? Customers blame developers, arguing that sloppy practices lead to low-quality software. Developers blame customers (and other stakeholders), arguing that irrational delivery dates and a continuing stream of changes force them to deliver software before it has been fully validated. Who’s right? Both—and that’s the problem. In this chapter, we consider software quality as a concept and examine why it’s worthy of serious consideration whenever software engineering practices are applied.

15.1 什么是质量?

15.1 What Is Quality?

罗伯特·佩尔西格 (Robert Persig) [Per74]在他的神秘著作《禅与摩托车维护艺术》中评论了我们所说的质量

In his mystical book Zen and the Art of Motorcycle Maintenance, Robert Persig [Per74] commented on the thing we call quality:

质量 。。。你知道它是什么,但你不知道它是什么。但这是自相矛盾的。但有些事情比其他事情更好;也就是说,它们具有更高的质量。但当你试图说出质量是什么时,除了拥有质量的东西之外,一切都变得糟糕了!没什么可谈的。。。显然有些事情比其他事情要好。。。但有什么好处呢?。。。你就这么一圈又一圈地转,精神轮子旋转着,却找不到任何地方可以得到牵引力。质量到底是什么?它是什么?

Quality . . . you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others; that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk about . . . Obviously some things are better than others . . . but what’s the betterness? . . . So round and round you go, spinning mental wheels and nowhere finding anyplace to get traction. What the hell is Quality? What is it?

确实——那是什么?

Indeed—what is it?

在更务实的层面上,哈佛商学院的 David Garvin [Gar84] 认为“质量是一个复杂且多方面的概念”,可以从五个不同的角度来描述。先验观点(如佩尔西格)认为,质量是你立即认识到但无法明确定义的东西。用户视图根据最终用户的特定目标来看待质量。如果产品满足这些目标,它就展现出质量。制造商的观点根据产品的原始规格来定义质量。如果产品符合规格,则表明其质量良好。产品观点表明,质量可以与产品的固有特性(例如功能和特性)联系在一起。最后,基于价值的观点根据客户愿意为产品支付的价格来衡量质量。事实上,质量包含所有这些观点以及更多内容。

At a somewhat more pragmatic level, David Garvin [Gar84] of the Harvard Business School suggests that “quality is a complex and multifaceted concept” that can be described from five different points of view. The transcendental view argues (like Persig) that quality is something you immediately recognize but cannot explicitly define. The user view sees quality in terms of an end user’s specific goals. If a product meets those goals, it exhibits quality. The manufacturer’s view defines quality in terms of the original specification of the product. If the product conforms to the spec, it exhibits quality. The product view suggests that quality can be tied to inherent characteristics (e.g., functions and features) of a product. Finally, the value-based view measures quality based on how much a customer is willing to pay for a product. In reality, quality encompasses all these views and more.

设计质量是指设计师为产品指定的特征。材料等级、公差和性能规格都有助于设计质量。随着使用更高等级的材料,规定了更严格的公差和更高的性能水平,如果产品按照规格制造,那么产品的设计质量也会提高。

Quality of design refers to the characteristics that designers specify for a product. The grade of materials, tolerances, and performance specifications all contribute to the quality of design. As higher-grade materials are used, tighter tolerances and greater levels of performance are specified, and the design quality of a product increases if the product is manufactured according to specifications.

在软件开发中,设计质量包括设计满足需求模型中指定的功能和特性的程度。一致性质量侧重于实施遵循设计以及最终系统满足其要求和性能目标的程度。

In software development, quality of design encompasses the degree to which the design meets the functions and features specified in the requirements model. Quality of conformance focuses on the degree to which the implementation follows the design and the resulting system meets its requirements and performance goals.

但是设计质量和一致性质量是软件工程师必须考虑的唯一问题吗?Robert Glass [Gla98] 认为更“直观”的关系是正确的:

But are quality of design and quality of conformance the only issues that software engineers must consider? Robert Glass [Gla98] argues that a more “intuitive” relationship is in order:

用户满意度 = 合规的产品 + 良好的质量 + 在预算和进度内交付

user satisfaction = compliant product + good quality + delivery within budget and schedule

第312页Glass 认为,归根结底,质量很重要,但如果用户不满意,其他一切都不重要。DeMarco [DeM98] 强化了这一观点,他说:“产品的质量取决于它使世界变得更好的程度。” 这种质量观认为,如果软件产品为其最终用户提供了实质性的好处,他们可能愿意容忍偶尔的可靠性或性能问题。软件质量的现代观点需要关注客户满意度以及符合产品要求 [Max16]。

Page 312At the bottom line, Glass contends that quality is important, but if the user isn’t satisfied, nothing else really matters. DeMarco [DeM98] reinforces this view when he states: “A product’s quality is a function of how much it changes the world for the better.” This view of quality contends that if a software product provides substantial benefit to its end users, they may be willing to tolerate occasional reliability or performance problems. A modern view of software quality requires attention to customer satisfaction as well as conformance to the product requirements [Max16].

15.2 软件质量

15.2 Software Quality

即使是最厌倦的软件开发人员也会同意高质量的软件是一个重要的目标。但我们如何定义软件质量呢?从最一般的意义上来说,软件质量可以定义为:以创建有用产品的方式应用的有效软件过程,该产品为生产者和使用者提供可衡量的价值。

Even the most jaded software developers will agree that high-quality software is an important goal. But how do we define software quality? In the most general sense, software quality can be defined as: An effective software process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it.

毫无疑问,前面的定义可以被修改或扩展,并且可以无休止地争论。就本书而言,该定义旨在强调三个要点:

There is little question that the preceding definition could be modified or extended and debated endlessly. For the purposes of this book, the definition serves to emphasize three important points:

  1. 有效的软件流程建立了支持构建高质量软件产品的任何努力的基础架构。流程的管理方面创建了制衡机制,有助于避免项目混乱——这是导致质量差的一个关键因素。软件工程实践使开发人员能够分析问题并设计可靠的解决方案——这两者对于构建高质量软件都至关重要。最后,诸如变更管理和技术审查之类的伞式活动与软件工程实践的任何其他部分一样与质量相关。

  2. An effective software process establishes the infrastructure that supports any effort at building a high-quality software product. The management aspects of process create the checks and balances that help avoid project chaos—a key contributor to poor quality. Software engineering practices allow the developer to analyze the problem and design a solid solution—both critical to building high-quality software. Finally, umbrella activities such as change management and technical reviews have as much to do with quality as any other part of software engineering practice.

  3. 有用的产品可以提供最终用户所需的内容、功能和特性,但同样重要的是,它以可靠、无错误的方式提供这些资产。有用的产品总是满足利益相关者明确提出的那些要求。此外,它还满足所有高质量软件所期望的一组隐含要求(例如,易用性)。

  4. A useful product delivers the content, functions, and features that the end user desires, but as important, it delivers these assets in a reliable, error-free way. A useful product always satisfies those requirements that have been explicitly stated by stakeholders. In addition, it satisfies a set of implicit requirements (e.g., ease of use) that are expected of all high-quality software.

  5. 通过为软件产品的生产者和用户增加价值,高质量的软件为软件组织和最终用户社区带来好处。软件组织获得了附加值,因为高质量的软件需要更少的维护工作、更少的错误修复和更少的客户支持。这使得软件工程师能够花更多时间创建新应用程序,减少返工。用户社区获得了附加值,因为应用程序以加快某些业务流程的方式提供了有用的功能。最终结果是 (1) 增加软件产品收入,(2) 当应用程序支持业务流程时获得更好的盈利能力,和/或 (3) 提高对业务至关重要的信息的可用性。

  6. By adding value for both the producer and user of a software product, high-quality software provides benefits for the software organization and the end-user community. The software organization gains added value because high-quality software requires less maintenance effort, fewer bug fixes, and reduced customer support. This enables software engineers to spend more time creating new applications and less on rework. The user community gains added value because the application provides a useful capability in a way that expedites some business process. The end result is (1) greater software product revenue, (2) better profitability when an application supports a business process, and/or (3) improved availability of information that is crucial for the business.

15.2.1 质量因素

15.2.1 Quality Factors

软件工程文献中已经提出了几种软件质量模型和标准。David Garvin [Gar84] 写道,质量是一种多方面的现象,需要使用多种视角来评估它。McCall 和 Walters [McC77] 提出了一种思考和组织影响软件质量的因素的有用方法。他们的软件质量因素(如图15.1所示)集中在软件产品的三个方面:其运行特性、其承受变化的能力以及其对新环境的适应性。McCall 的质量因素为工程软件奠定了基础,通过关注软件产品提供的整体用户体验来提供高水平的用户满意度。除非开发人员确保需求规范正确并且在软件开发过程的早期消除缺陷[Max16],否则这是不可能完成的。第313页

Several software quality models and standards have been proposed in the software engineering literature. David Garvin [Gar84] writes that quality is a multifaceted phenomena and requires the use of multiple perspectives to assess it. McCall and Walters [McC77] proposed a useful way to think about and organize factors affecting software quality. Their software quality factors (shown in Figure 15.1) focus on three software product aspects: its operation characteristics, its ability to undergo change, and its adaptability to new environments. McCall’s quality factors provide a basis for engineering software that provides high levels of user satisfaction by focusing on the overall user experience delivered by the software product. This cannot be done unless developers ensure that the requirements specification is correct and that defects are removed early in the software development process [Max16].Page 313

图15.1 McCall 的软件 质量因素

Figure 15.1 McCall’s software quality factors

ISO 25010 质量模型是最新标准(2011 年创建,2017 年修订)。1本标准定义了两种质量模型。使用质量模型描述了考虑在特定环境中使用产品(例如,由人在特定平台上使用产品)时合适的五个特征。产品质量模型描述了关注计算机系统静态和动态性质的八个特征。

The ISO 25010 quality model is the newest standard (created in 2011 and revised in 2017).1 This standard defines two quality models. The quality in use model describes five characteristics that are appropriate when considering using the product in a particular context (e.g., using the product on a specific platform by a human). The product quality model describes eight characteristics that focus on both the static and dynamic nature of computer systems.

  • 使用质量模型

    • 效力。用户实现目标的准确性和完整性

    • 效率。为了以期望的准确性完全实现用户目标而花费的资源

    • 满意。有用、信任、愉悦、舒适

    • 免于风险。减轻经济、健康、安全和环境风险

    • 上下文覆盖。完整性、灵活性

  • Quality in Use Model

    • Effectiveness. Accuracy and completeness with which users achieve goals

    • Efficiency. Resources expended to achieve user goals completely with desired accuracy

    • Satisfaction. Usefulness, trust, pleasure, comfort

    • Freedom from risk. Mitigation of economic, health, safety, and environmental risks

    • Context coverage. Completeness, flexibility

  • 产品质量

    • 功能适用性。完整、正确、适当

    • 绩效效率。时间、资源利用率、容量

    • 兼容性。共存、互操作

    • 第314页可用性。适宜性、易学性、可操作性、防错性、美观性、可访问性

    • 可靠性。成熟度、可用性、容错性、可恢复性

    • 安全。保密、正直、责任、真实性

    • 可维护性。模块化、可重用性、可修改性、可测试性

    • 可移植性。适应性、可安装性、可替换性

  • Product Quality

    • Functional suitability. Complete, correct, appropriate

    • Performance efficiency. Timing, resource utilization, capacity

    • Compatibility. Coexistence, interoperability

    • Page 314Usability. Appropriateness, learnability, operability, error protection, aesthetics, accessibility

    • Reliability. Maturity, availability, fault tolerance, recoverability

    • Security. Confidentiality, integrity, accountability, authenticity

    • Maintainability. Modularity, reusability, modifiability, testability

    • Portability. Adaptability, installability, replaceability

添加使用质量模型有助于强调客户满意度在软件质量评估中的重要性。产品质量模型指出了评估软件产品的功能和非功能需求的重要性[Max16]。

The addition of the quality in use model helps to emphasize the importance of customer satisfaction in the assessment of software quality. The product quality model points out the importance of assessing both the functional and nonfunctional requirements for the software product [Max16].

15.2.2 定性质量评估

15.2.2 Qualitative Quality Assessment

第 15.2.1 节中提出的质量维度和因素侧重于完整的软件产品,可以用作应用程序质量的一般指示。您的软件团队可以开发一组质量特征和相关问题,以探究每个因素的满足程度。2例如,ISO 25010 将可用性确定为重要的质量因素。如果您被要求评估用户界面并评估其可用性,您会如何进行?

The quality dimensions and factors presented in Section 15.2.1 focus on the complete software product and can be used as a generic indication of the quality of an application. Your software team can develop a set of quality characteristics and associated questions that would probe the degree to which each factor has been satisfied.2 For example, ISO 25010 identifies usability as an important quality factor. If you were asked to evaluate a user interface and assess its usability, how would you proceed?

尽管为第 15.2.1 节中提到的质量因素开发定量度量很诱人,但您也可以创建一个简单的属性清单,以提供该因素存在的可靠指示。您可以从 ISO 25010 中建议的可用性子特性开始:适当性、可学习性、可操作性、错误保护、美观和可访问性。您和您的团队可能决定创建用户调查问卷和一组供用户执行的结构化任务。您可以在用户执行这些任务时观察他们,并在他们完成后让他们完成调查问卷。我们将在第 21 章中更详细地讨论可用性测试。

Although it’s tempting to develop quantitative measures for the quality factors noted in Section 15.2.1, you can also create a simple checklist of attributes that provide a solid indication that the factor is present. You might start with the sub-characteristics suggested for usability in ISO 25010: appropriateness, learnability, operability, error protection, aesthetics, and accessibility. You and your team might decide to create a user questionnaire and a set of structured tasks for users to perform. You might observe the users while they perform these tasks and have them complete the questionnaire when they finish. We will discuss usability testing in more detail in Chapter 21.

为了进行评估,您和您的团队需要解决界面的特定的、可测量的(或至少是可识别的)属性。您的任务可能集中于回答以下问题:

To conduct your assessment, you and your team will need to address specific, measurable (or at least, recognizable) attributes of the interface. Your tasks might be focused on answering the following questions:

  • 用户多久才能确定该软件产品是否可以用来帮助他们完成任务?(适当性)

  • How quickly can users determine whether the software product can be used to help them complete their task or not? (appropriateness)

  • 用户需要多长时间才能学会如何使用完成任务所需的系统功能?(易学性)

  • How long does it take users to learn how to use the system functions needed to complete their task? (learnability)

  • 用户是否能够在后续测试中回忆起如何使用系统功能而无需重新学习?(易学性)

  • Is the user able to recall how to use system functions in subsequent testing sessions without having to relearn them? (learnability)

  • 用户使用系统完成任务需要多长时间?(可操作性)

  • How long does it take users to complete tasks using the system? (operability)

  • 系统是否试图防止用户犯错误?(错误保护)

  • Does the system try to prevent users from making errors? (error protection)

  • 系统是否允许用户撤消可能导致错误的操作?(错误保护)

  • Does the system allow users to undo operations that may have resulted in errors? (error protection)

  • 对于有关用户界面外观的问题,答案是否给出了有利的回应?(美学)

  • Do answers give favorable responses to questions about the appearance of the user interface? (aesthetics)

  • 该界面是否符合第 12 章黄金法则所规定的期望?(无障碍)第315页

  • Does the interface conform to the expectations set forth by the golden rules from Chapter 12? (accessibility)Page 315

  • 用户界面是否符合目标用户所需的可访问性清单项目?(无障碍)

  • Does the user interface conform to the accessibility checklist items required for the intended users? (accessibility)

随着界面设计的开发,软件团队将审查设计原型并提出所指出的问题。如果大多数问题的答案是肯定的,则用户界面很可能表现出高质量。将为每个要评估的质量因素开发一系列与这些类似的问题。就可用性而言,观察代表性用户与系统的交互始终很重要。对于其他一些质量因素,在野外(或至少在生产环境中)测试软件可能很重要。

As the interface design is developed, the software team would review the design prototype and ask the questions noted. If the answer to most of these questions is yes, it is likely that the user interface exhibits high quality. A collection of questions similar to these would be developed for each quality factor to be assessed. In the case of usability, it is always important to observe representative users interact with the system. For some other quality factors it may be important to test the software in the wild (or at least in the production environment).

15.2.3 定量质量评估

15.2.3 Quantitative Quality Assessment

在前面的小节中,我们提出了一组用于“衡量”软件质量的定性因素。软件工程社区致力于开发精确的软件质量衡量标准,但有时会因活动的主观性而感到沮丧。卡瓦诺和麦考尔 [Cav78] 讨论了这种情况:

In the preceding subsections, we have presented a set of qualitative factors for the “measurement” of software quality. The software engineering community strives to develop precise measures for software quality and is sometimes frustrated by the subjective nature of the activity. Cavano and McCall [Cav78] discuss this situation:

主体性和专业性。。。适用于确定软件质量。为了帮助解决这个问题,需要对软件质量进行更精确的定义,并且需要某种方法来导出软件质量的定量测量结果以进行客观分析。。。由于不存在绝对的知识,因此人们不应期望准确地测量软件质量,因为每种测量都存在部分不完美的情况。

Subjectivity and specialization . . . apply to determining software quality. To help solve this problem, a more precise definition of software quality is needed as well as some way to derive quantitative measurements of software quality for objective analysis . . . Since there is no such thing as absolute knowledge, one should not expect to measure software quality exactly, for every measurement is partially imperfect.

可以使用软件指标来检测多个软件设计缺陷。该过程包括查找表明存在高耦合或不必要的复杂程度等问题的代码片段。内部代码属性可以使用软件度量来定量描述。每当为代码片段计算的软件度量值超出可接受值的范围时,就表明存在应调查的质量问题[Max16]。

Several software design defects can be detected using software metrics. The process consists of finding code fragments that suggest the presence of things like high coupling or unnecessary levels of complexity. Internal code attributes can be described quantitatively using software metrics. Any time software metric values computed for a code fragment fall outside the range of acceptable values, it signals the existence of a quality problem that should be investigated [Max16].

第 23 章中,我们将介绍一组可应用于软件质量定量评估的软件指标。在所有情况下,指标都代表间接测量;也就是说,我们从来没有真正衡量质量,而是衡量质量的某种表现。复杂的因素是测量的变量与软件质量之间的精确关系。

In Chapter 23, we’ll present a set of software metrics that can be applied to the quantitative assessment of software quality. In all cases, the metrics represent indirect measures; that is, we never really measure quality but rather some manifestation of quality. The complicating factor is the precise relationship between the variable that is measured and the quality of software.

15.3 软件质量困境

15.3 The Software Quality Dilemma

在网络上发布的采访 [Ven03] 中,Bertrand Meyer 讨论了我们所说的质量困境:

In an interview [Ven03] published on the Web, Bertrand Meyer discusses what we call the quality dilemma:

如果你生产的软件系统质量很差,你就会失败,因为没有人愿意购买它。另一方面,如果您花费无限的时间、极大的精力和巨额资金来构建绝对完美的软件,那么它需要很长时间才能完成,而且生产成本将非常昂贵,以至于您将无论如何,都失业了。要么你错过了市场窗口,要么你耗尽了你所有的资源。因此,业内人士试图达到一个神奇的中间立场,即产品足够好,不会立即被拒绝,例如在评估期间,但也不是太多完美主义和太多工作的对象,以至于需要很长时间或完成成本太高。

If you produce a software system that has terrible quality, you lose because no one will want to buy it. If on the other hand you spend infinite time, extremely large effort, and huge sums of money to build the absolutely perfect piece of software, then it’s going to take so long to complete and it will be so expensive to produce that you’ll be out of business anyway. Either you missed the market window, or you simply exhausted all your resources. So people in industry try to get to that magical middle ground where the product is good enough not to be rejected right away, such as during evaluation, but also not the object of so much perfectionism and so much work that it would take too long or cost too much to complete.

第316页可以说软件工程师应该努力生产高质量的系统。最好在尝试这样做时应用良好的实践。但迈耶所讨论的情况是现实生活中的,即使对于最好的软件工程组织来说,这也是一个两难的境地。当您面临质量困境时(每个人都曾在某个时候面临过这种困境),请尝试实现平衡 - 付出足够的努力来产生可接受的质量而不埋没项目。

Page 316It’s fine to state that software engineers should strive to produce high-quality systems. It’s even better to apply good practices in your attempt to do so. But the situation discussed by Meyer is real life and represents a dilemma for even the best software engineering organizations. When you’re faced with the quality dilemma (and everyone is faced with it at one time or another), try to achieve balance—enough effort to produce acceptable quality without burying the project.

15.3.1 “足够好”软件

15.3.1 “Good Enough” Software

坦白说,如果我们接受迈耶的论点,那么生产“足够好”的软件可以接受吗?这个问题的答案一定是肯定的,因为软件公司每天都在这样做[Rod17]。他们创建具有已知错误的软件并将其交付给广大最终用户。他们认识到 1.0 版本中提供的某些功能和特性可能不是最高质量,并计划在 2.0 版本中进行改进。他们知道有些客户会抱怨,但他们也认识到,只要交付的产品“足够好”,上市时间可能会胜过更好的质量。

Stated bluntly, if we are to accept the argument made by Meyer, is it acceptable to produce “good enough” software? The answer to this question must be yes, because software companies do it every day [Rod17]. They create software with known bugs and deliver it to a broad population of end users. They recognize that some of the functions and features delivered in version 1.0 may not be of the highest quality and plan for improvements in version 2.0. They do this knowing that some customers will complain, but they recognize that time to market may trump better quality as long as the delivered product is “good enough.”

究竟什么是“足够好”?足够好的软件可以提供最终用户所需的高质量功能和特性,但同时它也提供了包含已知错误的其他更模糊或专门的功能和特性。软件供应商希望绝大多数最终用户能够忽略这些错误,因为他们对其他应用程序功能非常满意。

Exactly what is “good enough”? Good enough software delivers high-quality functions and features that end users desire, but at the same time it delivers other more obscure or specialized functions and features that contain known bugs. The software vendor hopes that the vast majority of end users will overlook the bugs because they are so happy with other application functionality.

这个想法可能会引起很多读者的共鸣。如果您是其中之一,我们只能要求您考虑一些反对“足够好”的论点。确实,“足够好”可能适用于某些应用领域和一些主要的软件公司。毕竟,如果一家公司拥有大量的营销预算,并且能够说服足够多的人购买 1.0 版本,那么它就成功地锁定了这些人。正如我们之前提到的,它可以声称它将提高后续版本的质量。通过提供足够好的 1.0 版本,它垄断了市场。

This idea may resonate with many readers. If you’re one of them, we can only ask you to consider some of the arguments against “good enough.” It is true that “good enough” may work in some application domains and for a few major software companies. After all, if a company has a large marketing budget and can convince enough people to buy version 1.0, it has succeeded in locking them in. As we noted earlier, it can argue that it will improve quality in subsequent versions. By delivering a good enough version 1.0, it has cornered the market.

如果您在一家小公司工作,请警惕这种理念。当您交付足够好的(有缺陷的)产品时,您的公司声誉将面临永久性损害的风险。您可能永远没有机会交付 2.0 版本,因为不好的口碑可能会导致您的销售额直线下降和您的公司倒闭。

If you work for a small company, be wary of this philosophy. When you deliver a good enough (buggy) product, you risk permanent damage to your company’s reputation. You may never get a chance to deliver version 2.0 because bad buzz may cause your sales to plummet and your company to fold.

如果您从事某些应用程序领域(例如实时嵌入式软件)或构建与硬件集成的应用程序软件(例如汽车软件、电信软件),那么交付具有已知错误的软件可能会导致疏忽,并使您的公司面临昂贵的诉讼。在某些情况下,甚至可能构成犯罪。没有人想要足够好的飞机航空电子软件!Ebert 写道,软件过程模型应该提供明确的标准来指导开发人员确定什么对于预期的应用程序领域来说真正“足够好”[Ebe14]。

If you work in certain application domains (e.g., real-time embedded software) or build application software that is integrated with hardware (e.g., automotive software, telecommunications software), delivering software with known bugs can be negligent and open your company to expensive litigation. In some cases, it can even be criminal. No one wants good enough aircraft avionics software! Ebert writes that the software process model should provide clear criteria to guide developers to determine what is really “good enough” for the intended application domain [Ebe14].

因此,如果您认为“足够好”是解决软件质量问题的捷径,请谨慎行事。它可以工作,但仅适用于少数人,并且仅在有限的应用程序域中。3第317页

So, proceed with caution if you believe that “good enough” is a shortcut that can solve your software quality problems. It can work, but only for a few and only in a limited set of application domains.3Page 317

15.3.2 质量成本

15.3.2 The Cost of Quality

争论的内容是这样的:我们知道质量很重要,但它花费了我们时间和金钱——太多的时间和金钱来获得我们真正想要的软件质量水平。从表面上看,这个论点似乎是合理的(参见本节前面迈耶的评论)。毫无疑问,质量是有成本的,但缺乏质量也会带来成本——不仅对于必须忍受有缺陷的软件的最终用户,而且对于构建并必须维护该软件的软件组织也是如此。真正的问题是:我们应该担心哪些成本?要回答这个问题,您必须了解实现质量的成本和低质量软件的成本。

The argument goes something like this: We know that quality is important, but it costs us time and money—too much time and money to get the level of software quality we really want. On its face, this argument seems reasonable (see Meyer’s comments earlier in this section). There is no question that quality has a cost, but lack of quality also has a cost—not only to end users who must live with buggy software, but also to the software organization that has built and must maintain it. The real question is this: Which cost should we be worried about? To answer this question, you must understand both the cost of achieving quality and the cost of low-quality software.

质量成本包括在追求质量或执行与质量相关的活动中发生的所有成本以及质量缺陷的下游成本。为了了解这些成本,组织应该收集指标来为当前质量成本提供基线,识别降低这些成本的机会,并提供标准化的比较基础。质量成本可以分为与预防、评估和失败相关的成本。

The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities and the downstream costs of lack of quality. To understand these costs, an organization should collect metrics to provide a baseline for the current cost of quality, identify opportunities for reducing these costs, and provide a normalized basis of comparison. The cost of quality can be divided into costs associated with prevention, appraisal, and failure.

预防成本包括 (1) 计划和协调所有质量控制和质量保证活动所需的管理活动成本,(2) 开发完整需求和设计模型所需的额外技术活动成本,(3) 测试计划成本,以及 ( 4) 与这些活动相关的所有培训的费用。不要害怕承担巨大的预防成本。请放心,您的投资将带来丰厚的回报。

Prevention costs include (1) the cost of management activities required to plan and coordinate all quality control and quality assurance activities, (2) the cost of added technical activities to develop complete requirements and design models, (3) test planning costs, and (4) the cost of all training associated with these activities. Don’t be afraid to incur significant prevention costs. Rest assured that your investment will provide an excellent return.

评估成本包括“第一次”了解每个流程的产品状况的活动。评估成本的例子包括:(1)对软件工程工作产品进行技术审查(第 16 章)的成本,(2)数据收集和指标评估的成本(第 23 章),以及(3)测试和评估的成本。调试(第 19 章第 21 章)。

Appraisal costs include activities to gain insight into product condition the “first time through” each process. Examples of appraisal costs include: (1) the cost of conducting technical reviews (Chapter 16) for software engineering work products, (2) the cost of data collection and metrics evaluation (Chapter 23), and (3) the cost of testing and debugging (Chapters 19 through 21).

失败成本是指如果在将产品交付给客户之前没有出现任何错误,那么这些成本就会消失。故障成本可分为内部故障成本和外部故障成本。当您在发货前检测到产品存在错误时,就会产生内部故障成本。内部故障成本包括:(1) 进行返工(维修)以纠正错误所需的成本,(2) 返工无意中产生必须减轻的副作用时发生的成本,以及 (3) 与收集相关的成本允许组织评估失败模式的质量指标。外部故障成本与产品运送给客户后发现的缺陷相关。外部故障成本的示例包括投诉解决、产品退货和更换、帮助热线支持以及与保修工作相关的人工成本。声誉不佳以及由此造成的业务损失是另一种外部失败成本,虽然难以量化,但仍然非常真实。当生产出低质量的软件时,就会发生不好的事情。

Failure costs are those that would disappear if no errors appeared before shipping a product to customers. Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs are incurred when you detect an error in a product prior to shipment. Internal failure costs include: (1) the cost required to perform rework (repair) to correct an error, (2) the cost that occurs when rework inadvertently generates side effects that must be mitigated, and (3) the costs associated with the collection of quality metrics that allow an organization to assess the modes of failure. External failure costs are associated with defects found after the product has been shipped to the customer. Examples of external failure costs are complaint resolution, product return and replacement, help line support, and labor costs associated with warranty work. A poor reputation and the resulting loss of business is another external failure cost that is difficult to quantify but nonetheless very real. Bad things happen when low-quality software is produced.

Cem Kaner [Kan95] 在对拒绝考虑外部故障成本的软件开发人员的起诉书中指出:

In an indictment of software developers who refuse to consider external failure costs, Cem Kaner [Kan95] states:

许多外部失败成本(例如商誉)难以量化,因此许多公司在计算成本效益权衡时忽略了它们。其他外部故障成本可以在不提高客户满意度的情况下降低(例如,通过提供更便宜、质量较低的售后支持,或向客户收取支持费用)。通过忽视不良产品给客户带来的成本,质量工程师鼓励做出与质量相关的决策,这会伤害我们的客户,而不是取悦他们。第318页

Many of the external failure costs, such as goodwill, are difficult to quantify, and many companies therefore ignore them when calculating their cost-benefit tradeoffs. Other external failure costs can be reduced (e.g. by providing cheaper, lower-quality, post-sale support, or by charging customers for support) without increasing customer satisfaction. By ignoring the costs to our customers of bad products, quality engineers encourage quality-related decision-making that victimizes our customers, rather than delighting them.Page 318

正如预期的那样,当我们从预防到检测到内部故障再到外部故障成本时,发现和修复错误或缺陷的相对成本急剧增加。图 15.2基于 Boehm 和 Basili [Boe01b] 收集的数据并由 Cigital Inc. [Cig07] 说明,说明了这一现象。

As expected, the relative costs to find and repair an error or defect increase dramatically as we go from prevention to detection to internal failure to external failure costs. Figure 15.2, based on data collected by Boehm and Basili [Boe01b] and illustrated by Cigital Inc. [Cig07], illustrates this phenomenon.

15.2纠正错误和缺陷 的相对成本

Figure 15.2 Relative cost of correcting errors and defects

资料来源:Boehm、Barry 和 Basili、Victor R.,“软件缺陷减少前 10 名列表”,IEEE 计算机,卷。34、没有。1、2001 年 1 月。

Source: Boehm, Barry and Basili, Victor R., “Software Defect Reduction Top 10 List,” IEEE Computer, vol. 34, no. 1, January 2001.

在代码生成过程中纠正缺陷的行业平均成本约为每个错误 977 美元。如果在系统测试期间发现相同错误,则纠正该错误的行业平均成本为每个错误 7,136 美元。Cigital Inc. [Cig07] 考虑了一个大型应用程序,该应用程序在编码过程中引入了 200 个错误。

The industry average cost to correct a defect during code generation is approximately $977 per error. The industry average cost to correct the same error if it is discovered during system testing is $7,136 per error. Cigital Inc. [Cig07] considers a large application that has 200 errors introduced during coding.

根据行业平均数据,编码阶段发现并纠正缺陷的成本为每个缺陷 977 美元。因此,在此阶段纠正 200 个“关键”缺陷的总成本 (200 × 977 美元) 约为 195,400 美元。

According to industry average data, the cost of finding and correcting defects during the coding phase is $977 per defect. Thus, the total cost for correcting the 200 “critical” defects during this phase (200 × $977) is approximately $195,400.

行业平均数据显示,在系统测试阶段发现并纠正缺陷的成本为每个缺陷 7,136 美元。在这种情况下,假设系统测试阶段发现了大约 50 个关键缺陷(或者 Cigital 在编码阶段发现的缺陷中仅 25%),则查找和修复这些缺陷的成本 (50 × 7,136 美元) 将约为 356,800 美元。这还会导致 150 个严重错误未被发现和纠正。在维护阶段查找并修复剩余 150 个缺陷的成本 (150 × 14,102 美元) 将为 2,115,300 美元。因此,编码阶段后查找并修复 200 个缺陷的总成本将为 2,472,100 美元(2,115,300 美元 + 356,800 美元)。

Industry average data shows that the cost of finding and correcting defects during the system testing phase is $7,136 per defect. In this case, assuming that the system testing phase revealed approximately 50 critical defects (or only 25% of those found by Cigital in the coding phase), the cost of finding and fixing those defects (50 × $7,136) would have been approximately $356,800. This would also have resulted in 150 critical errors going undetected and uncorrected. The cost of finding and fixing these remaining 150 defects in the maintenance phase (150 × $14,102) would have been $2,115,300. Thus, the total cost of finding and fixing the 200 defects after the coding phase would have been $2,472,100 ($2,115,300 + $356,800).

即使您的软件组织的成本是行业平均水平的一半(大多数人不知道他们的成本是多少!),与早期质量控制和保证活动(在需求分析和设计期间进行)相关的成本节省也是引人注目的。第319页

Even if your software organization has costs that are half of the industry average (most have no idea what their costs are!), the cost savings associated with early quality control and assurance activities (conducted during requirements analysis and design) are compelling.Page 319

15.3.3 风险

15.3.3 Risks

在本书的第一章中,我们写道:“人们将自己的工作、舒适、安全、娱乐、决定以及生命都押在了计算机软件上。最好是对的。” 这意味着低质量的软件会增加开发人员和最终用户的风险。4在上一小节中,我们讨论了其中一个风险(成本)。但设计和实施不当的应用程序的缺点并不总是随着金钱和时间而停止。一个极端的例子[Gag04]也许可以说明这一点。

In Chapter 1 of this book, we wrote, “people bet their jobs, their comforts, their safety, their entertainment, their decisions, and their very lives on computer software. It better be right.” The implication is that low-quality software increases risks for both the developer and the end user.4 In the preceding subsection, we discussed one of these risks (cost). But the downside of poorly designed and implemented applications does not always stop with dollars and time. An extreme example [Gag04] might serve to illustrate.

2000 年 11 月,巴拿马一家医院的 28 名患者在接受多种癌症治疗期间接受了大量过量的伽马射线治疗。在接下来的几个月里,其中 5 名患者死于辐射中毒,另外 15 名患者出现严重并发症。是什么原因造成了这场悲剧呢?医院技术人员对一家美国公司开发的软件包进行了修改,以计算每个患者修改后的辐射剂量。

Throughout the month of November 2000 at a hospital in Panama, 28 patients received massive overdoses of gamma rays during treatment for a variety of cancers. In the months that followed, 5 of these patients died from radiation poisoning and 15 others developed serious complications. What caused this tragedy? A software package, developed by a U.S. company, was modified by hospital technicians to compute modified doses of radiation for each patient.

第320页三名巴拿马医学物理学家对软件进行了调整以提供额外的功能,被指控犯有二级谋杀罪。这家美国公司在两个国家面临严重诉讼。盖奇和麦考密克评论:

Page 320The three Panamanian medical physicists, who tweaked the software to provide additional capability, were charged with second-degree murder. The U.S. company was faced with serious litigation in two countries. Gage and McCormick comment:

对于医疗技术人员来说,这并不是一个警示故事,尽管如果他们误解或滥用技术,他们可能会发现自己正在努力避免入狱。这也不是一个关于人类如何因设计不当或解释不当的软件而受到伤害或更糟的故事,尽管有很多例子可以说明这一点。这是对任何计算机程序创建者的警告:软件质量很重要,应用程序必须万无一失,而且无论是嵌入汽车发动机、工厂机器人手臂还是医院康复设备中,部署不当代码可以杀人。

This is not a cautionary tale for medical technicians, even though they can find themselves fighting to stay out of jail if they misunderstand or misuse technology. This also is not a tale of how human beings can be injured or worse by poorly designed or poorly explained software, although there are plenty of examples to make the point. This is a warning for any creator of computer programs: that software quality matters, that applications must be foolproof, and that—whether embedded in the engine of a car, a robotic arm in a factory or a healing device in a hospital—poorly deployed code can kill.

质量差会带来风险,有些风险非常严重。5

Poor quality leads to risks, some of them very serious.5

15.3.4 疏忽和责任

15.3.4 Negligence and Liability

这个故事太常见了。政府或企业实体聘请主要的软件开发商或咨询公司来分析需求,然后设计和构建基于软件的“系统”来支持某些主要活动。该系统可能支持主要的公司职能(例如,养老金管理)或某些政府职能(例如,医疗保健管理或国土安全)。

The story is all too common. A governmental or corporate entity hires a major software developer or consulting company to analyze requirements and then design and construct a software-based “system” to support some major activity. The system might support a major corporate function (e.g., pension management) or some governmental function (e.g., health care administration or homeland security).

工作开始时双方都是出于最好的意图,但当系统交付时,情况却变糟了。系统延迟,无法提供所需的特性和功能,容易出错,并且不符合客户的认可。随之而来的是诉讼。

Work begins with the best of intentions on both sides, but by the time the system is delivered, things have gone bad. The system is late, fails to deliver desired features and functions, is error-prone, and does not meet with customer approval. Litigation ensues.

在大多数情况下,客户声称开发人员存在疏忽(以应用软件实践的方式),因此无权获得付款。开发人员经常声称客户多次改变其需求,并以其他方式破坏了开发伙伴关系。在每种情况下,所交付系统的质量都会受到质疑。

In most cases, the customer claims that the developer has been negligent (in the manner in which it has applied software practices) and is therefore not entitled to payment. The developer often claims that the customer has repeatedly changed its requirements and has subverted the development partnership in other ways. In every case, the quality of the delivered system comes into question.

15.3.5 质量和安全

15.3.5 Quality and Security

随着基于 Web 和移动系统的重要性不断增长,应用程序安全性也变得越来越重要。简而言之,质量不高的软件更容易被黑客攻击,因此,低质量的软件会间接增加安全风险及其随之而来的成本和问题。

As the criticality of Web-based and mobile systems grows, application security has become increasingly important. Stated simply, software that does not exhibit high quality is easier to hack, and as a consequence, low-quality software can indirectly increase the security risk with all its attendant costs and problems.

在接受 ComputerWorld 采访时作者兼安全专家 Gary McGraw 评论道 [Wil05]:

In an interview in ComputerWorld, author and security expert Gary McGraw comments [Wil05]:

软件安全完全与质量相关。您必须在开始、设计、架构、测试和编码阶段以及整个软件生命周期[过程]中考虑安全性、可靠性、可用性、可靠性。即使是意识到软件安全问题的人也将注意力集中在生命周期后期的问题上。越早发现软件问题越好。软件问题有两种。一是bug,即实现问题。另一个是软件缺陷——设计中的架构问题。人们对错误关注太多,而对缺陷关注不够。

Software security relates entirely and completely to quality. You must think about security, reliability, availability, dependability—at the beginning, in the design, architecture, test, and coding phases, all through the software life cycle [process]. Even people aware of the software security problem have focused on late life-cycle stuff. The earlier you find the software problem, the better. And there are two kinds of software problems. One is bugs, which are implementation problems. The other is software flaws—architectural problems in the design. People pay too much attention to bugs and not enough on flaws.

要构建安全的系统,您必须关注质量,而这种关注必须在设计过程中开始。本书第二部分讨论的概念和方法带来了减少“缺陷”的软件架构。第 18 章对安全工程进行了更详细的讨论。第321页

To build a secure system, you must focus on quality, and that focus must begin during design. The concepts and methods discussed in Part Two of this book lead to a software architecture that reduces “flaws.” A more detailed discussion of security engineering is presented in Chapter 18.Page 321

15.3.6 管理行为的影响

15.3.6 The Impact of Management Actions

软件质量通常受到管理决策和技术决策的影响。即使是最好的软件工程实践也可能被糟糕的业务决策和有问题的项目管理行为所颠覆。

Software quality is often influenced as much by management decisions as it is by technology decisions. Even the best software engineering practices can be subverted by poor business decisions and questionable project management actions.

在本书的第四部分中,我们在软件过程的背景下讨论项目管理。当每个项目任务启动时,项目负责人将做出可能对产品质量产生重大影响的决策。

In Part Four of this book we discuss project management within the context of the software process. As each project task is initiated, a project leader will make decisions that can have a significant impact on product quality.

估计决策。在确定交付日期和指定总体预算之前,软件团队很少有机会提供项目估算。相反,团队会进行“健全性检查”,以确保交付日期和里程碑是合理的。在许多情况下,巨大的上市时间压力迫使团队接受不切实际的交付日期。因此,人们会走捷径,可能会跳过导致更高质量软件的活动,并且产品质量也会受到影响。如果交货日期不合理,保持立场很重要。解释为什么您需要更多时间,或者建议可以在分配的时间内交付(高质量)的功能子集。

Estimation Decisions. A software team is rarely given the luxury of providing an estimate for a project before delivery dates are established and an overall budget is specified. Instead, the team conducts a “sanity check” to ensure that delivery dates and milestones are rational. In many cases there is enormous time-to-market pressure that forces a team to accept unrealistic delivery dates. As a consequence, shortcuts are taken, activities that lead to higher-quality software may be skipped, and product quality suffers. If a delivery date is irrational, it is important to hold your ground. Explain why you need more time, or alternatively, suggest a subset of functionality that can be delivered (with high quality) in the time allotted.

调度决策。当建立软件项目进度表(第 25 章)时,任务将根据依赖关系进行排序。例如,由于组件A依赖于组件B、CD 内发生的处理,因此在组件B、CD完全测试之前,无法安排组件A进行测试。项目进度表将反映这一点。但是,如果时间非常短,并且A必须可用于进一步的关键测试,您可能会决定测试A,而不测试其从属组件(其运行速度稍微落后于计划),以便您可以将其用于必须完成的其他测试交货之前。毕竟,最后期限即将到来。因此,A可能存在隐藏的缺陷,直到很久以后才被发现。质量受到影响。

Scheduling Decisions. When a software project schedule is established (Chapter 25), tasks are sequenced based on dependencies. For example, because component A depends on processing that occurs within components B, C, and D, component A cannot be scheduled for testing until components B, C, and D are fully tested. A project schedule would reflect this. But if time is very short, and A must be available for further critical testing, you might decide to test A without its subordinate components (which are running slightly behind schedule), so that you can make it available for other testing that must be done before delivery. After all, the deadline looms. As a consequence, A may have defects that are hidden, only to be discovered much later. Quality suffers.

以风险为导向的决策。风险管理(第 26 章)是成功软件项目的关键属性之一。您确实需要知道可能会出现什么问题,并在出现问题时制定应急计划。太多的软件团队更喜欢盲目乐观,在假设不会出错的情况下制定开发计划。更糟糕的是,他们没有办法处理确实出错的事情。因此,当风险成为现实时,就会出现混乱,随着疯狂程度的增加,质量水平必然会下降。

Risk-Oriented Decisions. Risk management (Chapter 26) is one of the key attributes of a successful software project. You really do need to know what might go wrong and establish a contingency plan if it does. Too many software teams prefer blind optimism, establishing a development schedule under the assumption that nothing will go wrong. Worse, they don’t have a way of handling things that do go wrong. As a consequence, when a risk becomes a reality, chaos reigns, and as the degree of craziness rises, the level of quality invariably falls.

软件质量困境可以通过梅斯基门定律来最好地概括:永远没有时间把事情做好,但总是有时间重新做一遍。我们的建议:花时间把事情做好几乎永远不会是错误的决定。

The software quality dilemma can best be summarized by stating Meskimen’s law: There’s never time to do it right, but always time to do it over again. Our advice: Taking the time to do it right is almost never the wrong decision.

15.4 实现软件质量

15.4 Achieving Software Quality

软件质量不仅仅是出现的。它是良好的项目管理和扎实的软件工程实践的结果。管理和实践应用于帮助软件团队实现高软件质量的四大活动:软件工程方法、项目管理技术、质量控制措施和软件质量保证。第322页

Software quality doesn’t just appear. It is the result of good project management and solid software engineering practice. Management and practice are applied within the context of four broad activities that help a software team achieve high software quality: software engineering methods, project management techniques, quality control actions, and software quality assurance.Page 322

15.4.1 软件工程方法

15.4.1 Software Engineering Methods

如果您期望构建高质量的软件,您必须了解要解决的问题。您还必须能够创建符合问题的设计,同时展现出导致软件表现出第15.2 节中讨论的质量维度和因素的特征。

If you expect to build high-quality software, you must understand the problem to be solved. You must also be capable of creating a design that conforms to the problem while at the same time exhibiting characteristics that lead to software that exhibits the quality dimensions and factors discussed in Section 15.2.

在本书的第二部分中,我们提出了一系列广泛的概念和方法,可以使人们对问题有一个相当完整的理解,并进行全面的设计,为构建活动奠定坚实的基础。如果应用这些概念并采用适当的分析和设计方法,创建高质量软件的可能性将大大增加。

In Part Two of this book, we presented a wide array of concepts and methods that can lead to a reasonably complete understanding of the problem and a comprehensive design that establishes a solid foundation for the construction activity. If you apply those concepts and adopt appropriate analysis and design methods, the likelihood of creating high-quality software will increase substantially.

15.4.2 项目管理技术

15.4.2 Project Management Techniques

不良管理决策对软件质量的影响已在第 15.3.6 节中讨论。其含义很明确:如果 (1) 项目经理使用估算来验证交付日期是否可以实现,(2) 了解进度依赖性并且团队抵制使用捷径的诱惑,(3) 进行风险规划,这样就不会出现问题滋生混乱,软件质量将会受到积极的影响。

The impact of poor management decisions on software quality has been discussed in Section 15.3.6. The implications are clear: If (1) a project manager uses estimation to verify that delivery dates are achievable, (2) schedule dependencies are understood and the team resists the temptation to use shortcuts, (3) risk planning is conducted so problems do not breed chaos, software quality will be affected in a positive way.

此外,项目计划应包括明确的质量和变更管理技术。本书第四部分讨论了实现良好项目管理实践的技术。

In addition, the project plan should include explicit techniques for quality and change management. Techniques that lead to good project management practices are discussed in Part Four of this book.

15.4.3 机器学习和缺陷预测

15.4.3 Machine Learning and Defect Prediction

缺陷预测[Mun17] 是识别可能存在质量问题的软件组件的重要部分。缺陷预测模型使用统计技术来检查软件度量和包含已知软件缺陷的软件组件之间的关系。它们可以成为软件开发人员快速识别容易出现缺陷的类的高效且有效的方法。这可以降低成本和开发时间 [Mal16]。

Defect prediction [Mun17] is an important part of identifying software components that may have quality concerns. Defect prediction models use statistical techniques to examine the relationships among combinations of software metrics and software components containing known software defects. They can be an efficient and effective way for software developers to quickly identify defect-prone classes. This can reduce costs and development times [Mal16].

机器学习是人工智能 (AI) 技术的应用,它使系统能够从经验中学习和改进,而无需明确编程。换句话说,机器学习专注于开发可以访问数据并使用数据进行自我学习的计算机程序。机器学习技术可用于自动发现软件指标和缺陷组件之间的预测关系的过程[Ort17]、[Li16]、[Mal16]。

Machine learning is an application of artificial intelligence (AI) techniques that provide systems with the ability to learn and improve from experience without being explicitly programmed. Stated another way, machine learning focuses on the development of computer programs that can access data and use the data to learn for themselves. Machine learning techniques can be used to automate the process of discovering predictive relationships between software metrics and defective components [Ort17], [Li16], [Mal16].

机器学习系统处理包含缺陷和无缺陷软件组件指标的代表性组合的大型数据集。这些数据用于调整分类算法。一旦系统通过这种类型的训练建立了预测模型,它就可以用于与未来软件产品相关的数据的质量评估和缺陷预测。构建这些类型的分类器是现代数据科学家工作的重要组成部分。关于数据科学和软件工程的使用的更多讨论出现在本书的附录 2中。

Machine learning systems process large data sets containing representative combinations of metrics for defective and nondefective software components. These data are used to tune classification algorithms. Once the system has built a prediction model though this type of training, it can be used for quality assessment and defect prediction on data associated with future software products. Building these types of classifiers is a big part of what modern data scientists do. More discussion on the use of data science and software engineering appears in Appendix 2 of this book.

15.4.4 质量控制

15.4.4 Quality Control

质量控制包含一组软件工程操作,有助于确保每个工作产品满足其质量目标。对模型进行审查以确保它们完整且一致。在测试开始之前,可以检查代码以发现并纠正错误。应用一系列测试步骤来发现处理逻辑、数据操作和接口通信中的错误。当任何这些工作产品未能满足质量目标时,测量和反馈的结合允许软件团队调整流程。本书第三部分的其余部分详细讨论了质量控制活动。第323页

Quality control encompasses a set of software engineering actions that help to ensure that each work product meets its quality goals. Models are reviewed to ensure that they are complete and consistent. Code may be inspected to uncover and correct errors before testing commences. A series of testing steps is applied to uncover errors in processing logic, data manipulation, and interface communication. A combination of measurement and feedback allows a software team to tune the process when any of these work products fails to meet quality goals. Quality control activities are discussed in detail throughout the remainder of Part Three of this book.Page 323

15.4.5 质量保证

15.4.5 Quality Assurance

质量保证建立了支持可靠的软件工程方法、合理的项目管理和质量控制操作的基础设施——如果您打算构建高质量的软件,所有这些都至关重要。此外,质量保证包括一组审核和报告功能,用于评估质量控制措施的有效性和完整性。质量保证的目标是为管理和技术人员提供了解产品质量所需的数据,从而获得洞察力和信心,确保实现产品质量的行动正在发挥作用。当然,如果通过质量保证提供的数据发现了问题,那么管理层就有责任解决这些问题并运用必要的资源来解决质量问题。软件质量保证将在第 17 章中详细讨论。

Quality assurance establishes the infrastructure that supports solid software engineering methods, rational project management, and quality control actions—all pivotal if you intend to build high-quality software. In addition, quality assurance consists of a set of auditing and reporting functions that assess the effectiveness and completeness of quality control actions. The goal of quality assurance is to provide management and technical staff with the data necessary to be informed about product quality, thereby gaining insight and confidence that actions to achieve product quality are working. Of course, if the data provided through quality assurance identifies problems, it is management’s responsibility to address the problems and apply the necessary resources to resolve quality issues. Software quality assurance is discussed in detail in Chapter 17.

15.5 总结

15.5 Summary

随着软件融入我们日常生活的方方面面,人们对基于软件的系统的质量越来越关注。但很难对软件质量进行全面的描述。在本章中,质量被定义为一种有效的软件过程,其应用方式可以创建有用的产品,为生产者和使用者提供可衡量的价值。

Concern for the quality of the software-based systems has grown as software becomes integrated into every aspect of our daily lives. But it is difficult to develop a comprehensive description of software quality. In this chapter, quality has been defined as an effective software process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it.

多年来,人们提出了各种各样的软件质量维度和因素。所有这些都试图定义一组特征,如果实现这些特征,将带来高软件质量。McCall 和 ISO 25010 质量因素将可靠性、可用性、可维护性、功能性和可移植性等特征确立为质量存在的指标。

A wide variety of software quality dimensions and factors has been proposed over the years. All try to define a set of characteristics that, if achieved, will lead to high software quality. McCall’s and the ISO 25010 quality factors establish characteristics such as reliability, usability, maintainability, functionality, and portability as indicators that quality exists.

每个软件组织都面临着软件质量的困境。本质上,每个人都想构建高质量的系统,但在市场驱动的世界中,生产“完美”软件所需的时间和精力根本无法获得。问题是,我们应该构建“足够好”的软件吗?尽管许多公司都这样做,但必须考虑一个重大的缺点。

Every software organization is faced with the software quality dilemma. In essence, everyone wants to build high-quality systems, but the time and effort required to produce “perfect” software are simply unavailable in a market-driven world. The question becomes, Should we build software that is “good enough”? Although many companies do just that, there is a significant downside that must be considered.

无论选择哪种方法,质量确实都有成本,可以从预防、评估和失败方面进行讨论。预防成本包括所有旨在首先预防缺陷的软件工程行动。评估成本与评估软件工作产品以确定其质量的操作相关。失败成本包括失败的内部代价和质量差造成的外部影响。

Regardless of the approach that is chosen, quality does have a cost that can be discussed in terms of prevention, appraisal, and failure. Prevention costs include all software engineering actions that are designed to prevent defects in the first place. Appraisal costs are associated with those actions that assess software work products to determine their quality. Failure costs encompass the internal price of failure and the external effects that poor quality precipitates.

软件质量是通过应用软件工程方法、可靠的管理实践和全面的质量控制来实现的——所有这些都得到软件质量保证基础设施的支持。在接下来的章节中,将详细讨论质量控制和保证。

Software quality is achieved through the application of software engineering methods, solid management practices, and comprehensive quality control—all supported by a software quality assurance infrastructure. In the chapters that follow, quality control and assurance are discussed in some detail.

第324页

Page 324

问题与思考点

Problems and Points to Ponder

15.1. 描述一下在申请大学之前您将如何评估该大学的质量。哪些因素会很重要?哪一个是至关重要的?

15.1. Describe how you would assess the quality of a university before applying to it. What factors would be important? Which would be critical?

15.2. 使用第 15.2 节中提出的软件质量定义,您认为是否有可能在不使用有效流程的情况下创建一个提供可衡量价值的有用产品?解释你的答案。

15.2. Using the definition of software quality proposed in Section 15.2, do you think it’s possible to create a useful product that provides measurable value without using an effective process? Explain your answer.

15.3。使用第 15.2.1 节中为 ISO 25010 质量因素“可维护性”指出的子属性,提出一组问题来探讨这些属性是否存在。请遵循第 15.2.2 节中所示的示例。

15.3. Using the subattributes noted for the ISO 25010 quality factor “maintainability” in Section 15.2.1, develop a set of questions that explore whether or not these attributes are present. Follow the example shown in Section 15.2.2.

15.4。用你自己的话描述软件质量困境。

15.4. Describe the software quality dilemma in your own words.

15.5。什么是“足够好”的软件?列出您认为是使用“足够好”理念开发的特定公司和特定产品。

15.5. What is “good enough” software? Name a specific company and specific products that you believe were developed using the good enough philosophy.

15.6。考虑到质量成本的四个方面,您认为哪一个是最昂贵的,为什么?

15.6. Considering each of the four aspects of the cost of quality, which do you think is the most expensive and why?

15.7。进行网络搜索,找到其他三个对公众造成“风险”的例子,这些风险可以直接追溯到低劣的软件质量。考虑从 http://catless.ncl.ac.uk/risks 开始搜索。

15.7. Do a Web search and find three other examples of “risks” to the public that can be directly traced to poor software quality. Consider beginning your search at http://catless.ncl.ac.uk/risks.

15.8。质量安全是一回事吗?解释。

15.8. Are quality and security the same thing? Explain.

15.9。解释为什么我们许多人继续遵循梅斯基门定律。软件业务的什么原因导致了这种情况?

15.9. Explain why it is that many of us continue to live by Meskimen’s law. What is it about the software business that causes this?

1 ISO 25010 可在 https://www.iso.org/standard/35733.html 上找到。

1 The ISO 25010 can be found at https://www.iso.org/standard/35733.html.

2这些特征和问题将作为软件审查的一部分得到解决(第 16 章)。

2 These characteristics and questions would be addressed as part of a software review (Chapter 16).

3关于“足够好”软件的优缺点的值得讨论的内容可以在 [Bre02] 中找到。

3 A worthwhile discussion of the pros and cons of “good enough” software can be found in [Bre02].

4在一篇题为“‘最令人震惊的软件失败’奖颁发给 . 。”。Chelsea Frischnecht 提供了一些可能出现问题的简短示例。该文章可在 https://www.tricentis.com/blog/2017/03/01/software-fail-awards/ 找到。

4 In an article titled “And the ‘Most Shocking Software Failure’ Award Goes To . . .” Chelsea Frischnecht provides a few brief examples of what can go wrong. The article can be found at https://www.tricentis.com/blog/2017/03/01/software-fail-awards/.

5 2019 年初,一家大型飞机制造商生产的飞行控制软件出现错误,与两起坠机事故和 346 人死亡直接相关。

5 In early 2019, an error in the flight control software produced by a major aircraft manufacturer was directly linked to two crashes and the deaths of 346 people.

第325页

Page 325

章节

chapter

16评论——推荐的方法

16 Reviews—A Recommended Approach

软件评审是软件过程工作流程的“过滤器”。太少了,流量就变得“肮脏”。太多了,水流就会减慢成细流。评审应用于软件工程过程中的各个阶段,旨在发现错误和缺陷。软件审查“净化”软件工程工作产品,包括需求和设计模型、代码和测试数据。使用指标,您可以确定哪些评论有效并强调它们,同时从流程中删除无效的评论以加速流程。

Software reviews are a “filter” for the software process work flow. Too few, and the flow is “dirty.” Too many, and the flow slows to a trickle. Reviews are applied at various points during software engineering and serve to uncover errors and defects. Software reviews “purify” software engineering work products, including requirements and design models, code, and testing data. Using metrics, you can determine which reviews work and emphasize them and at the same time remove ineffective reviews from the flow to accelerate the process.

第326页许多不同类型的评审可以作为软件工程的一部分进行。每个都有它的位置。如果讨论技术问题,围绕咖啡机举行的非正式会议也是一种审查形式。向客户、管理人员和技术人员等受众正式介绍软件架构也是一种审查形式。然而,在本书中,我们重点关注技术同行评审,例如随意评审、演练检查。从质量控制的角度来看,技术审查(TR)是最有效的过滤器。TR 由软件工程师和其他利益相关者为所有项目团队成员进行,是发现错误和提高软件质量的有效手段。

Page 326Many different types of reviews can be conducted as part of software engineering. Each has its place. An informal meeting around the coffee machine is a form of review, if technical problems are discussed. A formal presentation of software architecture to an audience of customers, management, and technical staff is also a form of review. In this book, however, we focus on technical or peer reviews, exemplified by casual reviews, walkthroughs, and inspections. A technical review (TR) is the most effective filter from a quality control standpoint. Conducted by software engineers and other stakeholders for all project team members, the TR is an effective means for uncovering errors and improving software quality.

16.1 软件缺陷的成本影响

16.1 Cost Impact of Software Defects

在软件过程的上下文中,术语“缺陷”“故障”是同义词。两者都意味着在软件发布给最终用户(或软件过程中的另一个框架活动)发现的质量问题。在前面的章节中,我们使用术语错误来描述软件工程师(或其他人)在将软件发布给最终用户(或软件过程中的另一个框架活动)之前发现的质量问题。

Within the context of the software process, the terms defect and fault are synonymous. Both imply a quality problem that is discovered after the software has been released to end users (or to another framework activity in the software process). In earlier chapters, we used the term error to depict a quality problem that is discovered by software engineers (or others) before the software is released to the end user (or to another framework activity in the software process).

第327页正式技术审查 (FTR) 的主要目标是在将错误传递给其他软件工程活动或发布给最终用户之前发现错误。技术审查的明显好处是及早发现错误,这样它们就不会传播到软件过程​​的下一步。

Page 327The primary objective of a formal technical review (FTR) is to find errors before they are passed on to another software engineering activity or released to the end user. The obvious benefit of technical reviews is the early discovery of errors so that they do not propagate to the next step in the software process.

许多行业研究表明,软件流程中 50% 到 65% 的错误(最终是所有缺陷)是由设计活动造成的。然而,事实证明,审查技术在发现设计缺陷方面的效率高达 75% [Jon86]。通过检测并消除大部分错误,审查过程大大降低了软件过程中后续活动的成本。我们几十年来就知道这一点,但仍然有许多开发人员不相信花在评审上的时间几乎总是少于重写不良代码所需的时间 [Yad17]。

A number of industry studies indicate that design activities introduce between 50 and 65 percent of all errors (and ultimately, all defects) during the software process. However, review techniques have been shown to be up to 75 percent effective [Jon86] in uncovering design flaws. By detecting and removing a large percentage of these errors, the review process substantially reduces the cost of subsequent activities in the software process. We have known this for decades, and yet there are still many developers who do not believe the time spent on reviews is almost always less than the time required to rewrite bad code [Yad17].

16.2 缺陷放大和消除

16.2 Defect Amplification and Removal

缺陷放大是一个最初在大约四十年前提出的概念[IBM81]。它有助于证明在软件审查上所付出的努力是合理的。从本质上讲,缺陷放大提出了以下论点——在软件工程工作流程的早期(例如,在需求建模期间)引入并且未被检测到的错误,可以并且经常会在设计期间被放大为多个错误。如果这些错误没有被发现(使用有效的审查),它们本身可能会在编码过程中进一步放大为更多错误。早期引入的单个错误如果没有被发现和纠正,可能会在流程后期放大为多个错误。缺陷传播是一个术语,用于描述未发现的错误对未来开发活动或产品行为的影响 [Vit17]。

Defect amplification is a concept originally proposed almost four decades ago [IBM81]. It helps to justify the effort expended on software reviews. In essence, defect amplification makes the following argument—an error introduced early in the software engineering work flow (e.g., during requirement modeling) and undetected, can and often will be amplified into multiple errors during design. If those errors are not uncovered (using effective reviews), they themselves may be further amplified into still more errors during coding. A single error introduced early and not uncovered and corrected can amplify into multiple errors later in the process. Defect propagation is a term used to describe the impact an undiscovered error has on future development activities or product behavior [Vit17].

随着开发团队深入软件流程,查找和修复错误的成本就会增加。缺陷放大和传播加剧了这种简单的现实,因为单个错误可能会在下游变成多个错误。查找和修复单个错误的成本可能很高,但查找和修复由单个早期错误传播的多个错误的成本要高得多。

As a development team moves deeper into the software process, the cost of finding and fixing an error grows. This simple reality is exacerbated by defect amplification and propagation because a single error may become multiple errors downstream. The cost of finding and fixing a single error can be signficant, but the cost to find and fix multiple errors propagated by a single earlier error is substantially more significant.

要进行审查,您必须花费时间和精力,并且您的开发组织必须花钱。然而,缺陷放大和传播的现实毫无疑问您可以现在支付或以后支付更多费用。这就是技术债务第 11 章)的全部内容 [Xia16] [Vit17]。

To conduct reviews, you must expend time and effort, and your development organization must spend money. However, the reality of defect amplification and propagation leaves little doubt that you can pay now or pay much more later. This is what technical debt (Chapter 11) is all about [Xia16] [Vit17].

16.3 审查指标及其使用

16.3 Review Metrics and Their Use

技术审查是良好软件工程实践所需的众多行动之一。每一个动作都需要人类的奉献精神。由于可用的项目工作量是有限的,因此对于软件工程组织来说,通过定义一组可用于评估其功效的指标(第 23 章)来了解每个操作的有效性非常重要。第328页

Technical reviews are one of many actions that are required as part of good software engineering practice. Each action requires dedicated human effort. Because available project effort is finite, it is important for a software engineering organization to understand the effectiveness of each action by defining a set of metrics (Chapter 23) that can be used to assess their efficacy.Page 328

尽管可以为技术审查定义许多指标,但相对较小的子集可以提供有用的见解。可以为每次进行的审核收集以下审核指标:

Although many metrics can be defined for technical reviews, a relatively small subset can provide useful insight. The following review metrics can be collected for each review that is conducted:

  • 准备工作, E p。在实际审查会议之前审查工作产品所需的工作量(以人小时为单位)

  • Preparation effort, Ep. The effort (in person-hours) required to review a work product prior to the actual review meeting

  • 评估工作量, E a。实际审核期间花费的精力(以人小时为单位)

  • Assessment effort, Ea. The effort (in person-hours) that is expended during the actual review

  • 返工工作, E r。致力于纠正审查期间发现的错误的工作量(以人小时为单位)

  • Rework effort, Er. The effort (in person-hours) that is dedicated to the correction of those errors uncovered during the review

  • 审查努力, E审查。代表审核工作量的总和:

    E评论= E p + E a + E r

  • Review effort, Ereview. Represents the sum of effort measures for reviews:

    Ereview = Ep + Ea + Er

  • 工作产品尺寸 (WPS)。已审查的工作产品大小的度量(例如,UML 模型的数量、文档页数或代码行数)

  • Work product size (WPS). A measure of the size of the work product that has been reviewed (e.g., the number of UML models, the number of document pages, or the number of lines of code)

  • 发现小错误,Errminor 发现的可归类为次要错误的数量(需要少于一些预先指定的努力来纠正)

  • Minor errors found, Errminor. The number of errors found that can be categorized as minor (requiring less than some prespecified effort to correct)

  • 发现重大错误, Err Major。发现的可归类为重大错误的数量(需要超出一些预先指定的努力来纠正)

  • Major errors found, Errmajor. The number of errors found that can be categorized as major (requiring more than some prespecified effort to correct)

  • 发现错误总数, Err tot。表示发现的错误的总和:

    错误=错误+大错误

  • Total errors found, Errtot. Represents the sum of the errors found:

    Errtot = Errminor + Errmajor

  • 错误密度。表示所审查的每个工作单元产品中发现的错误:

  • Error density. Represents the errors found per unit of work product reviewed:

如何使用这些指标?例如,考虑一个需求模型,该模型经过审查以发现错误、不一致和遗漏。可以通过几种不同的方式计算错误密度。假设需求模型包含 18 个 UML 图,作为 32 页描述性材料的一部分。审查发现小错误18处,重大错误4处。因此,Err tot = 22。错误密度为每个 UML 图 1.2 个错误,或每个需求模型页 0.68 个错误。

How might these metrics be used? As an example, consider a requirements model that is reviewed to uncover errors, inconsistencies, and omissions. It would be possible to compute the error density in several different ways. Assume the requirements model contains 18 UML diagrams as part of 32 overall pages of descriptive materials. The review uncovers 18 minor errors and 4 major errors. Therefore, Errtot = 22. Error density is 1.2 errors per UML diagram, or 0.68 errors per requirements model page.

如果对许多不同类型的工作产品(例如,需求模型、设计模型、代码、测试用例)进行审查,则可以根据所有审查发现的错误总数来计算每次审查发现的错误的百分比。此外,还可以计算每个工作产品的错误密度。

If reviews are conducted for a number of different types of work products (e.g., requirements model, design model, code, test cases), the percentage of errors uncovered for each review can be computed against the total number of errors found for all reviews. In addition, the error density for each work product can be computed.

一旦收集了跨多个项目进行的多次审阅的数据,错误密度的平均值使您能够在审阅新文档之前估计在新文档中发现的错误数量。例如,如果需求模型的平均错误密度为每页 0.68 个错误,而新的需求模型有 40 页长,则粗略估计表明您的软件团队在审查文档期间将发现大约 27 个错误。如果您只发现 9 个错误,那么您要么在开发需求模型方面做得非常好,要么您的审查方法不够彻底。

Once data are collected for many reviews conducted across many projects, average values for error density enable you to estimate the number of errors to be found in a new document before it is reviewed. For example, if the average error density for a requirements model is 0.68 errors per page, and a new requirements model is 40 pages long, a rough estimate suggests that your software team will find around 27 errors during the review of the document. If you find only 9 errors, you’ve either done an extremely good job in developing the requirements model or your review approach was not thorough enough.

第329页实时衡量任何技术审查的成本效益都是很困难的。软件工程组织只有在完成评审、收集评审指标、计算平均数据、然后测量软件的下游质量(通过测试)后才能评估评审的有效性及其成本效益。

Page 329It is difficult to measure the cost effectiveness of any technical review in real time. A software engineering organization can assess the effectiveness of reviews and their cost benefit only after reviews have been completed, review metrics have been collected, average data have been computed, and then the downstream quality of the software is measured (via testing).

返回到前面的示例,需求模型的平均错误密度被确定为每页 0.68。已发现纠正较小模型错误(在审核后立即)所需的工作量需要 4 个人时。发现重大需求错误所需的工作量为 18 人时。检查收集的审阅数据,您会发现小错误发生的频率大约是大错误的六倍。因此,您可以估计在审核期间查找并纠正需求错误的平均工作量约为 6 人时。

Returning to the previous example, the average error density for requirements models was determined to be 0.68 per page. The effort required to correct a minor model error (immediately after the review) has been found to require 4 person-hours. The effort required for a major requirement error has been found to be 18 person-hours. Examining the review data collected, you find that minor errors occur about six times more frequently than major errors. Therefore, you can estimate that the average effort to find and correct a requirements error during review is about 6 person-hours.

测试期间发现的与需求相关的错误平均需要 45 个人小时来查找和纠正(没有关于错误相对严重程度的数据)。使用记录的平均值,我们得到:

Requirements-related errors uncovered during testing require an average of 45 person-hours to find and correct (no data are available on the relative severity of the error). Using the averages noted, we get:

每个错误节省的精力 = E测试- E评论

Effort saved per error = EtestingEreviews

= 45 − 6 = 39 人时/错误

= 45 − 6 = 39 person-hours/error

由于在审查需求模型期间发现了 22 个错误,因此节省了约 858 人时的测试工作量。这仅适用于与需求相关的错误。与设计和代码相关的错误会增加整体收益。

Because 22 errors were found during the review of the requirements model, a savings of about 858 person-hours of testing effort would be achieved. And that’s just for requirements-related errors. Errors associated with design and code would add to the overall benefit.

最重要的是,节省的精力可以缩短交付周期并缩短上市时间。本节中提供的示例表明这可能是正确的。更重要的是,软件评论的行业数据已经收集了三十多年,并使用图 16.1所示的图表进行了定性总结。

The bottom line—effort saved leads to shorter delivery cycles and improved time to market. The example presented in this section suggests this may be true. More importantly, industry data for software reviews has been collected for more than three decades and is summarized qualitatively using the graphs shown in Figure 16.1.

图16.1 有审核和无审核所花费的精力

Figure 16.1 Effort expended with and without reviews

资料来源:Fagan, Michael E.,“软件检查的进展”,IEEE 软件工程汇刊,卷。SE-12,没有。7,1986 年 7 月,744-751。

Source: Fagan, Michael E., “Advances in Software Inspections,” IEEE Transactions on Software Engineering, vol. SE-12, no. 7, July 1986, 744–751.

参考该图,在软件增量开发的早期,使用评审时所花费的精力确实会增加,但这种早期的评审投资会带来回报,因为测试和纠正工作减少了。需要注意的是,有审核的开发部署日期比没有审核的部署日期要早。评论不需要时间;他们救了它!

Referring to the figure, the effort expended when reviews are used does increase early in the development of a software increment, but this early investment for reviews pays dividends because testing and corrective effort is reduced. It is important to note that the deployment date for development with reviews is sooner than the deployment date without reviews. Reviews don’t take time; they save it!

第330页

Page 330

16.4 评审类型的标准

16.4 Criteria for Types of Reviews

技术审查可以分为正式审查和非正式审查,或者介于这两个极端之间。正式程度的选择要与要构建的产品类型、项目时间表以及从事这项工作的人员相匹配。图 16.2描述了技术审查的参考模型 [Lai02],它确定了有助于审查进行的正式性的四个特征。

Technical reviews can be classified as either formal or informal or somewhere in between these two extremes. The level of formality is chosen to match the type of product to be built, the project time line, and the people who are doing the work. Figure 16.2 depicts a reference model for technical reviews [Lai02] that identifies four characteristics that contribute to the formality with which a review is conducted.

16.2 技术审查参考模型

Figure 16.2 Reference model for technical reviews

每个参考模型特征都有助于定义审核正式程度。当 (1) 为审核者明确定义不同的角色,(2) 有足够的审核计划和准备,(3) 独特的审核结构(包括任务和内部工作)时,审核的正式性就会增加产品)被定义,并且(4)评审者对所做的任何更正进行跟进。

Each of the reference model characteristics helps to define the level of review formality. The formality of a review increases when (1) distinct roles are explicitly defined for the reviewers, (2) there is a sufficient amount of planning and preparation for the review, (3) a distinct structure for the review (including tasks and internal work products) is defined, and (4) follow-up by the reviewers occurs for any corrections that are made.

该模型中未呈现的一个元素是评论本身的频率。如果您使用的敏捷原型模型(第 4 章)包含相对较短的冲刺,您的团队可能会选择不太正式的审查,因为审查发生得相当频繁。这通常意味着可以更快、更频繁地发现缺陷。

An element that is not presented in this model is the frequency of the reviews themselves. If you are using an agile prototyping model (Chapter 4) that contains relatively short sprints, your team may opt for less formal reviews because the reviews are happening fairly often. This usually means that defects are caught sooner and more often.

为了理解参考模型,我们假设您决定查看SafeHomeAssured.com 的界面设计。您可以通过各种不同的方式来做到这一点,从相对随意到极其严格。如果您认为休闲方法最合适,您可以请几位同事(同行)检查界面原型,以发现潜在的问题。你们所有人都决定不进行预先准备,但将以合理结构化的方式评估原型——首先考虑布局,其次考虑美观,然后考虑导航选项,等等。作为设计师,您决定做一些笔记,但不做正式的笔记。第331页

To understand the reference model, let’s assume that you’ve decided to review the interface design for SafeHomeAssured.com. You can do this in a variety of different ways that range from relatively casual to extremely rigorous. If you decide that the casual approach is most appropriate, you ask a few colleagues (peers) to examine the interface prototype in an effort to uncover potential problems. All of you decide that there will be no advance preparation, but that you will evaluate the prototype in a reasonably structured way—looking at layout first, aesthetics next, navigation options after that, and so on. As the designer, you decide to take a few notes, but nothing formal.Page 331

但如果界面对于整个项目的成功至关重要怎么办?如果人类的生命依赖于符合人体工程学的界面会怎样?您可能会认为需要采取更严格的方法。将成立一个审查小组。团队中的每个人都扮演着特定的角色——领导团队、记录发现、展示材料等等。每个审阅者在审阅之前都将有权访问工作产品(在本例中为界面原型),并会花时间查找错误、不一致和遗漏。将根据审查前制定的议程执行一系列具体任务。审查的结果将被正式记录,团队将根据审查的结果决定工作产品的状态。审查小组的成员还可以验证所做的更正是否正确完成。

But what if the interface is pivotal to the success of the entire project? What if human lives depended on an interface that was ergonomically sound? You might decide that a more rigorous approach was necessary. A review team would be formed. Each person on the team would have a specific role to play—leading the team, recording findings, presenting the material, and so on. Each reviewer would be given access to the work product (in this case, the interface prototype) before the review and would spend time looking for errors, inconsistencies, and omissions. A set of specific tasks would be conducted based on an agenda that was developed before the review occurred. The results of the review would be formally recorded, and the team would decide on the status of the work product based on the outcome of the review. Members of the review team might also verify that the corrections made were done properly.

在本书中,我们考虑两大类技术评论:非正式评论和更正式的技术评论。在每个类别中,可以选择多种不同的方法。这些内容将在以下各节中介绍。

In this book we consider two broad categories of technical reviews: informal reviews and more formal technical reviews. Within each category, a number of different approaches can be chosen. These are presented in the sections that follow.

16.5 非正式评论

16.5 Informal Reviews

非正式评审包括与同事对软件工程工作产品进行简单的案头检查、为了评审工作产品而召开的非正式会议(涉及两个以上的人),或者结对编程中面向评审的方面(第 3 章

Informal reviews include a simple desk check of a software engineering work product with a colleague, a casual meeting (involving more than two people) for the purpose of reviewing a work product, or the review-oriented aspects of pair programming (Chapter 3).

一次简单的案头检查或与同事举行的非正式会议都是一次审查。然而,由于没有事先规划或准备,没有议程或会议结构,也没有对发现的错误进行后续行动,此类审查的有效性大大低于更正式的方法。但简单的桌面检查可以并且确实发现了可能进一步传播到软件流程中的错误。

A simple desk check or a casual meeting conducted with a colleague is a review. However, because there is no advance planning or preparation, no agenda or meeting structure, and no follow-up on the errors that are uncovered, the effectiveness of such reviews is considerably lower than more formal approaches. But a simple desk check can and does uncover errors that might otherwise propagate further into the software process.

提高案头检查审查效率的一种方法是为软件团队生成的每个主要工作产品开发一组简单的审查清单2 。检查表中提出的问题是通用的,但它们将有助于指导审阅者检查工作产品。例如,让我们重新检查一下SafeHomeAssured.com 界面原型的桌面检查。设计师和同事不是简单地在设计师的工作站上摆弄原型,而是使用接口清单检查原型:

One way to improve the efficacy of a desk check review is to develop a set of simple review checklists2 for each major work product produced by the software team. The questions posed within the checklist are generic, but they will serve to guide the reviewers as they check the work product. For example, let’s reexamine a desk check of the interface prototype for SafeHomeAssured.com. Rather than simply playing with the prototype at the designer’s workstation, the designer and a colleague examine the prototype using a checklist for interfaces:

  • 布局是使用标准约定设计的吗?左到右?从上到下?

  • Is the layout designed using standard conventions? Left to right? Top to bottom?

  • 演示文稿需要滚动吗?

  • Does the presentation need to be scrolled?

  • 颜色、布局、字体和尺寸是否得到有效使用?

  • Are color and placement, typeface, and size used effectively?

  • 所有导航选项或功能是否都以相同的抽象级别表示?

  • Are all navigation options or functions represented at the same level of abstraction?

  • 所有导航选项是否都有明确标记?

  • Are all navigation choices clearly labeled?

等等。审阅者指出的任何错误或问题都会由设计人员记录下来,以便稍后解决。桌面检查可以以临时方式安排,也可以作为良好软件工程实践的一部分强制执行。一般来说,审核的材料量相对较少,案头检查的总时间也就1、2个小时多一点。第332页

and so on. Any errors or issues noted by the reviewers are recorded by the designer for resolution at a later time. Desk checks may be scheduled in an ad hoc manner, or they may be mandated as part of good software engineering practice. In general, the amount of material to be reviewed is relatively small and the overall time spent on a desk check spans little more than 1 or 2 hours.Page 332

第 3 章中,我们通过以下方式描述了结对编程:XP 建议两个人在一台计算机工作站上一起工作,为一个故事创建代码。这提供了一种实时问题解决(两个头通常比一个更好)和实时质量保证的机制。

In Chapter 3, we described pair programming in the following manner: XP recommends that two people work together at one computer workstation to create code for a story. This provides a mechanism for real-time problem solving (two heads are often better than one) and real-time quality assurance.

结对编程(第 3.5.1 节)可以被描述为连续的桌面检查。结对编程不是在某个时间点安排评审,而是鼓励在创建工作产品(设计或代码)时进行持续评审。好处是立即发现错误并提高工作产品质量。

Pair programming (Section 3.5.1) can be characterized as a continuous desk check. Rather than scheduling a review at some point in time, pair programming encourages continuous review as a work product (design or code) is created. The benefit is immediate discovery of errors and better work product quality.

一些软件工程师认为,结对编程中固有的冗余是对资源的浪费。毕竟,为什么要分配两个人去完成一个人可以完成的工作呢?这个问题的答案可以在16.3节中找到。如果结对编程所产生的工作产品的质量明显优于个人的工作,那么与质量相关的节省就足以证明结对编程所隐含的“冗余”是合理的。

Some software engineers argue that the inherent redundancy built into pair programming is wasteful of resources. After all, why assign two people to a job that one person can accomplish? The answer to this question can be found in Section 16.3. If the quality of the work product produced as a consequence of pair programming is significantly better than the work of an individual, the quality-related savings can more than justify the “redundancy” implied by pair programming.

16.6 正式技术评审

16.6 Formal Technical Reviews

正式技术审查(FTR) 是由软件工程师(和其他人)执行的软件质量控制活动。FTR 的目标是: (1) 发现软件任何表示的功能、逻辑或实现中的错误;(2) 验证受审软件是否满足其要求;(3) 确保软件已按照预定义的标准表示;(四)实现软件开发的统一;(5) 使项目更易于管理。此外,FTR 还充当培训场,使初级工程师能够观察软件分析、设计和实现的不同方法。FTR 还可以促进备份和连续性,因为许多人开始熟悉他们以前可能没有见过的软件部分。

A formal technical review (FTR) is a software quality control activity performed by software engineers (and others). The objectives of an FTR are: (1) to uncover errors in function, logic, or implementation for any representation of the software; (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more manageable. In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because a number of people become familiar with parts of the software that they may not have otherwise seen.

FTR 实际上是一类审查,包括演练检查。每次 FTR 都是以会议形式进行的,只有经过适当的计划、控制和出席才能取得成功。在接下来的部分中,类似于演练的指南将作为代表性的正式技术审查提供。如果您对软件检查以及演练的其他信息感兴趣,请参阅 [Rad02]、[Wie02] 或 [Fre90]。

The FTR is actually a class of reviews that includes walkthroughs and inspections. Each FTR is conducted as a meeting and will be successful only if it is properly planned, controlled, and attended. In the sections that follow, guidelines similar to those for a walkthrough are presented as a representative formal technical review. If you have interest in software inspections, as well as additional information on walkthroughs, see [Rad02], [Wie02], or [Fre90].

16.6.1 评审会议

16.6.1 The Review Meeting

无论选择哪种 FTR 形式,每次审核会议都应遵守以下限制:

Regardless of the FTR format that is chosen, every review meeting should abide by the following constraints:

  • (通常)应有三到五个人参与审核。

  • Between three and five people (typically) should be involved in the review.

  • 应提前做好准备,但每人的工作时间不应超过 2 小时。

  • Advance preparation should occur but should require no more than 2 hours of work for each person.

  • 评审会议时间应不少于2小时。

  • The duration of the review meeting should be less than 2 hours.

第333页考虑到这些限制,很明显 FTR 侧重于整个软件的特定(且很小)部分。例如,不是尝试审查整个设计,而是对每个组件或一小组组件进行演练。通过缩小关注范围,FTR 发现错误的可能性更高。

Page 333Given these constraints, it should be obvious that an FTR focuses on a specific (and small) part of the overall software. For example, rather than attempting to review an entire design, walkthroughs are conducted for each component or small group of components. By narrowing the focus, the FTR has a higher likelihood of uncovering errors.

FTR 的重点是工作产品(例如,需求模型的独立部分、详细的组件设计或组件的源代码)。开发工作产品的个人(生产者通知项目负责人工作产品已完成并且需要进行审查。项目负责人联系审核负责人,审核负责人评估产品的准备情况,生成产品材料的副本,并将其分发给两到三名审核人员进行提前准备。每个审阅者预计将花费 1 到 2 小时审阅产品、做笔记或以其他方式熟悉工作。同时,审核负责人还审核产品并制定审核会议的议程,通常安排在第二天。

The focus of the FTR is on a work product (e.g., a self-contained portion of a requirements model, a detailed component design, or source code for a component). The individual who has developed the work product—the producer—informs the project leader that the work product is complete and that a review is required. The project leader contacts a review leader, who evaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation. Each reviewer is expected to spend between 1 and 2 hours reviewing the product, making notes, and otherwise becoming familiar with the work. Concurrently, the review leader also reviews the product and establishes an agenda for the review meeting, which is typically scheduled for the next day.

评审会议由评审组长、全体评审人员、制片人参加。其中一名评审员扮演记录员的角色,即(以书面形式)记录评审期间提出的所有重要问题的个人。FTR 首先介绍议程和制片人的简要介绍。然后,制作人继续“浏览”工作产品,解释材料,而审阅者则根据他们的预先准备提出问题。当发现有效的问题或错误时,记录员会逐一记录。不要太严厉地指出错误。一种温和的方法是提出一个问题,使生产者能够发现错误。

The review meeting is attended by the review leader, all reviewers, and the producer. One of the reviewers takes on the role of a recorder, that is, the individual who records (in writing) all important issues raised during the review. The FTR begins with an introduction of the agenda and a brief introduction by the producer. The producer then proceeds to “walk through” the work product, explaining the material, while reviewers raise issues based on their advance preparation. When valid problems or errors are discovered, the recorder notes each. Don’t point out errors too harshly. One way to be gentle is to ask a question that enables the producer to discover the error.

审查结束时,所有 FTR 参与者必须决定是否:(1)接受产品而不进行进一步修改,(2)因严重错误而拒绝该产品(一旦纠正,必须进行另一次审查),或( 3) 暂时接受产品(已遇到小错误,必须更正,但不需要额外审核)。做出决定后,所有 FTR 参与者都会完成签字,表明他们参与审核并同意审核小组的调查结果。

At the end of the review, all attendees of the FTR must decide whether to: (1) accept the product without further modification, (2) reject the product due to severe errors (once corrected, another review must be performed), or (3) accept the product provisionally (minor errors have been encountered and must be corrected, but no additional review will be required). After the decision is made, all FTR attendees complete a sign-off, indicating their participation in the review and their concurrence with the review team’s findings.

16.6.2 审查报告和记录保存

16.6.2 Review Reporting and Record Keeping

在 FTR 期间,审阅者(记录者)会主动记录已提出的所有问题。这些在审查会议结束时进行总结,并生成审查问题清单。此外,还完成了正式的技术审查总结报告。审查总结报告回答了三个问题:

During the FTR, a reviewer (the recorder) actively records all issues that have been raised. These are summarized at the end of the review meeting, and a review issues list is produced. In addition, a formal technical review summary report is completed. A review summary report answers three questions:

  1. 审查了什么?

  2. What was reviewed?

  3. 谁审查过它?

  4. Who reviewed it?

  5. 调查结果和结论是什么?

  6. What were the findings and conclusions?

审查摘要报告是单页表格(可能带有附件)。它成为项目历史记录的一部分,并可以分发给项目负责人和其他相关方。

The review summary report is a single-page form (with possible attachments). It becomes part of the project historical record and may be distributed to the project leader and other interested parties.

审查问题列表有两个目的:(1) 识别产品中的问题区域;(2) 作为行动项目清单,指导生产商进行纠正。问题列表通常附在摘要报告之后。

The review issues list serves two purposes: (1) to identify problem areas within the product and (2) to serve as an action item checklist that guides the producer as corrections are made. An issues list is normally attached to the summary report.

第334页您应该建立后续程序以确保问题列表中的项目已得到正确纠正。除非这样做,否则提出的问题可能会“被忽视”。一种方法是将跟进责任分配给审核领导者。

Page 334You should establish a follow-up procedure to ensure that items on the issues list have been properly corrected. Unless this is done, it is possible that issues raised can “fall between the cracks.” One approach is to assign the responsibility for follow-up to the review leader.

16.6.3 审查指南

16.6.3 Review Guidelines

必须提前制定进行正式技术审查的指南,分发给所有审查人员,达成一致,然后遵循。不受控制的审查通常比没有审查更糟糕。以下是正式技术审查的最低限度指南:

Guidelines for conducting formal technical reviews must be established in advance, distributed to all reviewers, agreed upon, and then followed. A review that is uncontrolled can often be worse than no review at all. The following represents a minimum set of guidelines for formal technical reviews:

  1. 审查产品,而不是生产商。FTR 涉及人和自我。如果进行得当,FTR 应该让所有参与者都有一种温暖的成就感。如果执行不当,FTR 可能会带有宗教裁判所的色彩。错误应当温和地指出;会议基调应宽松且具有建设性;目的不应是使人难堪或贬低。审核领导者应召开审核会议,确保保持适当的语气和态度,并应立即停止失控的审核。

  2. Review the product, not the producer. An FTR involves people and egos. Conducted properly, the FTR should leave all participants with a warm feeling of accomplishment. Conducted improperly, the FTR can take on the aura of an inquisition. Errors should be pointed out gently; the tone of the meeting should be loose and constructive; the intent should not be to embarrass or belittle. The review leader should conduct the review meeting to ensure that the proper tone and attitude are maintained and should immediately halt a review that has gotten out of control.

  3. 制定议程并维护它。各种类型会议的主要弊病之一就是漂移。FTR 必须保持在正轨上并按计划进行。审核领导者有责任维持会议日程,并且不应该害怕在出现偏差时推动人们。

  4. Set an agenda and maintain it. One of the key maladies of meetings of all types is drift. An FTR must be kept on track and on schedule. The review leader is chartered with the responsibility for maintaining the meeting schedule and should not be afraid to nudge people when drift sets in.

  5. 限制辩论和反驳。当审稿人提出某个问题时,可能无法就其影响达成普遍共识。与其花时间争论这个问题,不如将问题记录下来以供离线进一步讨论。

  6. Limit debate and rebuttal. When an issue is raised by a reviewer, there may not be universal agreement on its impact. Rather than spending time debating the question, the issue should be recorded for further discussion off-line.

  7. 阐明问题领域,但不要试图解决所有指出的问题。审查不是解决问题的会议。问题的解决通常可以由生产者单独完成或仅在另一个人的帮助下完成。问题的解决应推迟到审查会议之后。

  8. Enunciate problem areas, but don’t attempt to solve every problem noted. A review is not a problem-solving session. The solution of a problem can often be accomplished by the producer alone or with the help of only one other individual. Problem solving should be postponed until after the review meeting.

  9. 做书面笔记。有时记录员在墙板上做笔记是个好主意,以便其他审阅者在记录信息时可以评估措辞和优先级。

  10. Take written notes. It is sometimes a good idea for the recorder to make notes on a wall board, so that wording and priorities can be assessed by other reviewers as information is recorded.

  11. 限制参加人数并坚持提前准备。两个头比一个好,但 14 个头不一定比 4 个头好。将参与的人数保持在必要的最低限度。但所有审核组成员必须提前做好准备。

  12. Limit the number of participants and insist upon advance preparation. Two heads are better than one, but 14 are not necessarily better than 4. Keep the number of people involved to the necessary minimum. However, all review team members must prepare in advance.

  13. 为可能要审查的每种产品制定一份清单。检查表可帮助审核领导者组织 FTR 会议,并帮助每位审核者专注于重要问题。应该为分析、设计、编码甚至测试工作产品制定清单。

  14. Develop a checklist for each product that is likely to be reviewed. A checklist helps the review leader to structure the FTR meeting and helps each reviewer to focus on important issues. Checklists should be developed for analysis, design, code, and even testing work products.

  15. 为 FTR 分配资源并安排时间。为了使评审有效,应将其作为软件过程中的一项任务进行安排。此外,还应该为 FTR 不可避免的修改安排时间。

  16. Allocate resources and schedule time for FTRs. For reviews to be effective, they should be scheduled as a task during the software process. In addition, time should be scheduled for the inevitable modifications that will occur as the result of an FTR.

  17. 第335页为所有审稿人进行有意义的培训。培训应强调与流程相关的问题和审查的人类心理方面。

  18. Page 335Conduct meaningful training for all reviewers. The training should stress both process-related issues and the human psychological side of reviews.

  19. 查看您的早期评论。汇报有助于发现审查过程本身的问题。第一个要审查的产品应该是审查指南本身。

  20. Review your early reviews. Debriefing can be beneficial in uncovering problems with the review process itself. The very first product to be reviewed should be the review guidelines themselves.

由于许多变量(例如,参与者数量、工作产品类型、时间安排和长度、特定审核方法)都会对成功审核产生影响,因此软件组织应该进行试验以确定哪种方法在本地环境中最有效。

Because many variables (e.g., number of participants, type of work products, timing and length, specific review approach) have an impact on a successful review, a software organization should experiment to determine what approach works best in a local context.

在理想的情况下,每个软件工程工作产品都将接受正式的技术审查。在软件项目的现实世界中,资源有限且时间紧迫。因此,尽管评审作为质量控制机制的价值已得到认可,但评审常常被跳过。然而,完整的 FTR 资源应该用于那些可能容易出错的工作产品。

In an ideal setting, every software-engineering work product would undergo a formal technical review. In the real world of software projects, resources are limited and time is short. As a consequence, reviews are often skipped, even though their value as a quality control mechanism is recognized. However, full FTR resources should be used on those work products that are likely to be error prone.

第336页

Page 336

16.7 事后评估

16.7 Postmortem Evaluations

如果软件团队在软件交付给最终用户后花时间评估软件项目的结果,则可以学到很多经验教训。Baaz 和他的同事 [Baa10] 建议使用事后评估(PME) 作为一种机制来确定当软件工程过程和实践应用于特定项目时哪些是正确的,哪些是错误的。

Many lessons can be learned if a software team takes the time to evaluate the results of a software project after the software has been delivered to end users. Baaz and his colleagues [Baa10] suggest the use of a postmortem evaluation (PME) as a mechanism to determine what went right and what went wrong when software engineering process and practice is applied in a specific project.

与专注于特定工作产品的 FTR 不同,它更像是 Scrum 回顾(第 3.4.5 节)。PME 检查整个软件项目,重点关注“优点(即成就和积极经验)和挑战(问题和消极经验)”[Baa10]。PME 通常以研讨会的形式进行,软件团队的成员和利益相关者都会参加。目的是找出优点和挑战,并从中汲取经验教训。目的是对未来的流程和实践提出改进建议。许多软件工程师将 PME 文档视为项目存档中保存的最有价值的文档。

Unlike an FTR that focuses on a specific work product, it is more like a Scrum retrospective (Section 3.4.5). A PME examines the entire software project, focusing on both “excellences (that is, achievements and positive experiences) and challenges (problems and negative experiences)” [Baa10]. Often conducted in a workshop format, a PME is attended by members of the software team and stakeholders. The intent is to identify excellences and challenges and to extract lessons learned from both. The objective is to suggest improvements to both process and practice going forward. Many software engineers regard PME documents as some of the most valuable documents to save in the project archive.

16.8 敏捷评审

16.8 Agile Reviews

一些软件工程师对将任何类型的评审纳入敏捷开发过程的想法犹豫不决,这并不奇怪。然而,未能及早发现缺陷可能会耗费大量时间和资源。忽视技术债务并不能让它消失。敏捷开发人员与所有软件开发人员一样需要尽早(并且经常)发现缺陷。诚然,让敏捷开发人员使用指标可能有点困难,但其中许多指标可以不引人注目地收集。

It’s not surprising that some software engineers balk at the thought of including reviews of any kind in agile development processes. Yet failing to catch defects early can be costly in terms of time and resources. Ignoring technical debt does not make it go away. Agile developers have the same need to find defects early (and often) that all software developers have. Admittedly, it may be somewhat more difficult to get agile developers to make use of metrics, but many of them can be collected unobtrusively.

如果我们仔细研究一下 Scrum 框架(第 3.4 节),就会发现有几个地方进行了非正式和正式的审查。在冲刺计划会议期间,在选择要包含在下一个冲刺中的用户故事之前,将根据优先级对用户故事进行审查和排序。每日 Scrum 会议是一种非正式的方式,可确保团队成员都在处理相同的优先事项,并发现任何可能妨碍按时完成冲刺的缺陷。敏捷开发人员经常使用结对编程,这是另一种非正式的审查技术。冲刺评审会议通常使用类似于正式技术评审所讨论的指南进行。代码生产者遍历为冲刺选择的用户故事,并向产品负责人演示所有功能都已存在。与 FTR 不同,产品负责人对是否接受冲刺原型拥有最终决定权。

If we take a closer look at the Scrum framework (Section 3.4), there are several places where informal and formal reviews take place. During the sprint planning meeting, user stories are reviewed and ordered according to priority, before selecting the user stories to include in the next sprint. The daily Scrum meeting is an informal way to ensure that the team members are all working on the same priorities and to catch any defects that may prevent completing the sprint on time. Agile developers often use pair programming, another informal review technique. The sprint review meeting is often conducted using guidelines similar to those discussed for a formal technical review. The code producers walk through the user stories selected for the sprint and demonstrate to the product owner that all functionality is present. Unlike the FTR, the product owner has the final word on whether to accept the sprint prototype or not.

如果我们看一下我们推荐的流程模型的评估原型部分(第 4.5 节),该任务也可能作为正式的技术审查来进行,并添加开发风险评估。我们之前提到过(第 16.7 节),冲刺回顾会议与项目事后分析会议非常相似,因为开发团队正在尝试吸取经验教训。软件质量保证的一个主要方面是能够重复您的成功并避免重复您的错误。

If we look at the evaluate prototype portion of our recommended process model (Section 4.5), this task is also likely to be conducted as a formal technical review with development risk assessment added to it. We mentioned previously (Section 16.7) that the sprint retrospective meeting is really similar to the project postmortem meeting in that the development team is trying to capture its lessons learned. A major aspect of software quality assurance is being able to repeat your successes and avoid repeating your mistakes.

第337页

Page 337

16.9 总结

16.9 Summary

每次技术审查的目的是发现错误并发现可能对要部署的软件产生负面影响的问题。越早发现并纠正错误,错误传播到其他软件工程工作产品并自我放大的可能性就越小,从而导致纠正错误的工作量显着增加。

The intent of every technical review is to find errors and uncover issues that would have a negative impact on the software to be deployed. The sooner an error is uncovered and corrected, the less likely that error will propagate to other software engineering work products and amplify itself, resulting in significantly more effort to correct it.

为了确定质量控制活动是否有效,应收集一组指标。审核指标重点关注进行审核所需的工作量以及审核期间发现的错误的类型和严重性。收集指标数据后,它们可用于评估您进行的审核的有效性。行业数据表明,评论可带来可观的投资回报。

To determine whether quality control activities are working, a set of metrics should be collected. Review metrics focus on the effort required to conduct the review and the types and severity of errors uncovered during the review. Once metrics data are collected, they can be used to assess the efficacy of the reviews you do conduct. Industry data indicate that reviews provide a significant return on investment.

审查正式性的参考模型将人员扮演的角色、计划和准备、会议结构、纠正方法和验证确定为表明审查进行的正式程度的特征。非正式审查本质上是随意的,但仍然可以有效地用来发现错误。正式评审更加结构化,并且最有可能产生高质量的软件。

A reference model for review formality identifies the roles people play, planning and preparation, meeting structure, correction approach, and verification as the characteristics that indicate the degree of formality with which a review is conducted. Informal reviews are casual in nature but can still be used effectively to uncover errors. Formal reviews are more structured and have the highest probability of leading to high-quality software.

非正式审查的特点是最少的计划和准备以及很少的记录保存。案头检查和结对编程属于非正式审查类别。

Informal reviews are characterized by minimal planning and preparation and little record keeping. Desk checks and pair programming fall into the informal review category.

正式的技术审查是一种程式化的会议,事实证明,它对于发现错误非常有效。正式的技术审查为每个审查员确定了明确的角色,鼓励计划和提前准备,要求应用明确的审查指南,并要求保存记录和状态报告。

A formal technical review is a stylized meeting that has been shown to be extremely effective in uncovering errors. Formal technical reviews establish defined roles for each reviewer, encourage planning and advance preparation, require the application of defined review guidelines, and mandate record keeping and status reporting.

问题与思考点

Problems and Points to Ponder

16.1. 解释错误和缺陷之间的区别

16.1. Explain the difference between an error and a defect.

16.2. 为什么我们不能等到测试后才发现并纠正所有软件错误?

16.2. Why can’t we just wait until testing to find and correct all software errors?

16.3。假设需求模型中引入了 10 个错误,每个错误将以 2:1 的系数放大到设计中,另外引入 20 个设计错误,然后以 1.5:1 的比例放大到代码中,其中又引入了 30 个错误。进一步假设所有单元测试将发现所有错误的 30%,集成将发现剩余错误的 30%,验证测试将发现剩余错误的 50%。不进行任何审查。有多少错误会被释放给最终用户?

16.3. Assume that 10 errors have been introduced in the requirements model and that each error will be amplified by a factor of 2:1 into design and an additional 20 design errors are introduced and then amplified 1.5:1 into code where an additional 30 errors are introduced. Assume further that all unit testing will find 30 percent of all errors, integration will find 30 percent of the remaining errors, and validation tests will find 50 percent of the remaining errors. No reviews are conducted. How many errors will be released to the end users?

16.4。重新考虑问题 16.3中描述的情况,但现在假设进行了需求、设计和代码审查,并且在发现该步骤中的所有错误方面有 60% 的效率。有多少错误会被释放到现场?

16.4. Reconsider the situation described in Problem 16.3, but now assume that requirements, design, and code reviews are conducted and are 60 percent effective in uncovering all errors at that step. How many errors will be released to the field?

16.5。重新考虑问题 16.316.4中描述的情况。如果发布到现场的每个错误的查找和纠正成本为 4800 美元,而审核中发现的每个错误的查找和纠正成本为 240 美元,那么通过进行审核可以节省多少钱?

16.5. Reconsider the situation described in Problems 16.3 and 16.4. If each of the errors released to the field costs $4800 to find and correct and each error found in review costs $240 to find and correct, how much money is saved by conducting reviews?

16.6。用你自己的话描述图16.1的含义。

16.6. Describe the meaning of Figure 16.1 in your own words.

16.7。您能想到一些案头检查可能会带来问题而不是带来好处的例子吗?

16.7. Can you think of a few instances in which a desk check might create problems rather than provide benefits?

第338页16.8。只有每个人都提前做好准备,正式的技术审查才会有效。如何识别未做好准备的评审参与者?如果你是评审组长,你会做什么?

Page 33816.8. A formal technical review is effective only if everyone has prepared in advance. How do you recognize a review participant who has not prepared? What do you do if you’re the review leader?

16.9。敏捷流程模型中如何解决技术债务?

16.9. How is technical debt addressed in agile process models?

16.10。考虑第 16.6.3 节中提出的审查指南。您认为哪一个最重要?为什么?

16.10. Consider the review guidelines presented in Section 16.6.3. Which do you think is most important and why?

1如果考虑软件过程改进,从一个过程框架活动(例如,建模)传播到另一过程框架活动(例如,构造)的质量问题也可以称为“缺陷”,因为该问题应该在工作产品之前就被发现(例如,设计模型)被“发布”到下一个活动。

1 If software process improvement is considered, a quality problem that is propagated from one process framework activity (e.g., modeling) to another (e.g., construction) can also be called a “defect” because the problem should have been found before a work product (e.g., a design model) was “released” to the next activity.

2通过网络搜索实际上可以找到数百个技术审查清单。例如,可以从 https://courses.cs.washington.edu/courses/cse403/12wi/sections/12wi_code_review_checklist.pdf 下载有用的代码审查清单。

2 Literally hundreds of technical review checklists can be found via a web search. For example, a useful code review checklist can be downloaded from https://courses.cs.washington.edu/courses/cse403/12wi/sections/12wi_code_review_checklist.pdf.

第339页

Page 339

章节

chapter

17 号软件质量保证

17 Software Quality Assurance

本书中描述的软件工程方法致力于实现一个目标:按时生产高质量的软件。然而,许多读者会遇到这样一个问题:“什么是软件质量?”

The software engineering approach described in this book works toward a single goal: to produce on-time, high-quality software. Yet many readers will be challenged by the question: “What is software quality?”

第340页Philip Crosby [Cro79] 在他关于质量的里程碑式著作中,对这个问题给出了一个讽刺的答案:

Page 340Philip Crosby [Cro79], in his landmark book on quality, provides a wry answer to this question:

质量管理的问题并不是人们不知道的。问题在于他们认为自己确实知道什么。。。

The problem of quality management is not what people don’t know about it. The problem is what they think they do know . . .

在这方面,质量与性有很多共同点。每个人都赞成它。(当然,在某些条件下。)每个人都觉得自己理解这一点。(尽管他们不想解释。)每个人都认为执行只是遵循自然倾向的问题。(毕竟,我们确实相处得很好。)当然,大多数人认为这些领域的问题是由其他人造成的。(如果他们愿意花时间把事情做好就好了。)

In this regard, quality has much in common with sex. Everybody is for it. (Under certain conditions, of course.) Everyone feels they understand it. (Even though they wouldn’t want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that problems in these areas are caused by other people. (If only they would take the time to do things right.)

事实上,质量是一个具有挑战性的概念——我们在第 15 章中详细讨论了这个概念。1

Indeed, quality is a challenging concept—one that we addressed in some detail in Chapter 15.1

一些软件开发人员仍然认为,软件质量是在代码生成后才开始担心的。没有东西会离事实很远!软件质量保证(通常称为质量管理)是一项涵盖整个软件过程的活动(第 2 章)。

Some software developers continue to believe that software quality is something you begin to worry about after code has been generated. Nothing could be further from the truth! Software quality assurance (often called quality management) is an umbrella activity (Chapter 2) that is applied throughout the software process.

软件质量保证(SQA)包括(图 17.1):(1)SQA 过程,(2)具体的质量保证和质量控制任务(包括技术审查和多层测试策略),(3)有效的软件工程实践(方法和方法)工具),(4) 对所有软件工作产品及其变更的控制(第 22 章),(5) 确保遵守软件开发标准的程序(如果适用),以及 (6) 测量和报告机制。

Software quality assurance (SQA) encompasses (Figure 17.1): (1) an SQA process, (2) specific quality assurance and quality control tasks (including technical reviews and a multitiered testing strategy), (3) effective software engineering practice (methods and tools), (4) control of all software work products and the changes made to them (Chapter 22), (5) a procedure to ensure compliance with software development standards (when applicable), and (6) measurement and reporting mechanisms.

图17.1软件质量 保证

Figure 17.1 Software quality assurance

在本章中,我们重点关注管理问题和特定于流程的活动,这些活动使软件组织能够确保“在正确的时间以正确的方式做正确的事情”。

In this chapter, we focus on the management issues and the process-specific activities that enable a software organization to ensure that it does “the right things at the right time in the right way.”

第341页

Page 341

17.1 背景问题

17.1 Background Issues

对于任何生产供他人使用的产品的企业来说,质量控制和保证是必不可少的活动。在二十世纪之前,质量控制是制造产品的工匠的唯一责任。随着时间的推移和大规模生产技术变得普遍,质量控制成为由产品制造者以外的人执行的活动。

Quality control and assurance are essential activities for any business that produces products to be used by others. Prior to the twentieth century, quality control was the sole responsibility of the craftsperson who built a product. As time passed and mass production techniques became commonplace, quality control became an activity performed by people other than the ones who built the product.

第一个正式的质量保证和控制功能于 1916 年在贝尔实验室引入,并迅速传播到整个制造业。20 世纪 40 年代,人们提出了更正式的质量控制方法。这些依赖于测量和持续的过程改进[Dem86]作为质量管理的关键要素。

The first formal quality assurance and control function was introduced at Bell Labs in 1916 and spread rapidly throughout the manufacturing world. During the 1940s, more formal approaches to quality control were suggested. These relied on measurement and continuous process improvement [Dem86] as key elements of quality management.

软件开发质量保证的历史与硬件制造质量的历史相似。在计算的早期(20世纪50年代和1960年代),质量是程序员的唯一责任。软件质量保证标准在 20 世纪 70 年代被引入军事合同软件开发中,并迅速传播到商业领域的软件开发中 [IEE17]。扩展前面提出的定义,软件质量保证是确保软件高质量所需的“有计划和系统的行动模式”[Sch01]。质量保证责任的范围最好可以用曾经流行的汽车广告来描述:“质量是第一要务。” 对于软件来说,许多不同的群体都有软件质量保证的责任——软件工程师、项目经理、客户、销售人员以及在 SQA 小组中服务的个人。

The history of quality assurance in software development parallels the history of quality in hardware manufacturing. During the early days of computing (1950s and 1960s), quality was the sole responsibility of the programmer. Standards for quality assurance for software were introduced in military contract software development during the 1970s and have spread rapidly into software development in the commercial world [IEE17]. Extending the definition presented earlier, software quality assurance is a “planned and systematic pattern of actions” [Sch01] that are required to ensure high quality in software. The scope of quality assurance responsibility might best be characterized by paraphrasing a once-popular automobile commercial: “Quality Is Job #1.” The implication for software is that many different constituencies have software quality assurance responsibility—software engineers, project managers, customers, salespeople, and the individuals who serve within an SQA group.

SQA 小组担任客户的内部代表。也就是说,执行SQA的人必须从客户的角度来看待软件。软件是否充分满足第 15 章中提到的质量因素?软件工程实践是否按照预先制定的标准进行?作为 SQA 活动的一部分,技术学科是否正确履行了自己的职责?SQA 小组试图回答这些问题和其他问题,以确保软件质量得到维持。

The SQA group serves as the customer’s in-house representative. That is, the people who perform SQA must look at the software from the customer’s point of view. Does the software adequately meet the quality factors noted in Chapter 15? Have software engineering practices been conducted according to preestablished standards? Have technical disciplines properly performed their roles as part of the SQA activity? The SQA group attempts to answer these and other questions to ensure that software quality is maintained.

17.2 软件质量保证要素

17.2 Elements of Software Quality Assurance

软件质量保证涵盖了广泛的关注点和活动,重点关注软件质量的管理。这些可以总结为以下方式[Hor03]:

Software quality assurance encompasses a broad range of concerns and activities that focus on the management of software quality. These can be summarized in the following manner [Hor03]:

  • 标准。IEEE、ISO 和其他标准组织已经制定了大量的软件工程标准和相关文档。标准可以由软件工程组织自愿采用,也可以由客户或其他利益相关者强加。SQA 的工作是确保遵循已采用的标准并且所有工作产品均符合这些标准。

  • Standards. The IEEE, ISO, and other standards organizations have produced a broad array of software engineering standards and related documents. Standards may be adopted voluntarily by a software engineering organization or imposed by the customer or other stakeholders. The job of SQA is to ensure that standards that have been adopted are followed and that all work products conform to them.

  • 审查和审计。技术评审是软件工程师为软件工程师执行的质量控制活动(第16章)。他们的目的是发现错误。审核是 SQA 人员执行的一种审查,目的是确保软件工程工作遵循质量指南。例如,可以对审核过程进行审核,以确保审核的执行方式最有可能发现错误。第342页

  • Reviews and audits. Technical reviews are a quality control activity performed by software engineers for software engineers (Chapter 16). Their intent is to uncover errors. Audits are a type of review performed by SQA personnel with the intent of ensuring that quality guidelines are being followed for software engineering work. For example, an audit of the review process might be conducted to ensure that reviews are being performed in a manner that will lead to the highest likelihood of uncovering errors.Page 342

  • 测试。软件测试(第 19 章第 21 章)是一种质量控制功能,其主要目标是发现错误。SQA 的工作是确保测试得到正确的规划和有效的执行,从而最大程度地实现其主要目标。

  • Testing. Software testing (Chapters 19 through 21) is a quality control function that has one primary goal—to find errors. The job of SQA is to ensure that testing is properly planned and efficiently conducted so that it has the highest likelihood of achieving its primary goal.

  • 错误/缺陷收集和分析。提高的唯一方法是衡量你的表现。SQA 收集并分析错误和缺陷数据,以更好地了解错误是如何引入的以及哪些软件工程活动最适合消除错误。

  • Error/defect collection and analysis. The only way to improve is to measure how you’re doing. SQA collects and analyzes error and defect data to better understand how errors are introduced and what software engineering activities are best suited to eliminating them.

  • 更换管理层。变更是任何软件项目中最具破坏性的方面之一。如果管理不当,变革可能会导致混乱,而混乱几乎总是会导致质量低下。SQA 确保制定适当的变更管理实践(第 22 章)。

  • Change management. Change is one of the most disruptive aspects of any software project. If it is not properly managed, change can lead to confusion, and confusion almost always leads to poor quality. SQA ensures that adequate change management practices (Chapter 22) have been instituted.

  • 教育。每个软件组织都希望改进其软件工程实践。改进的一个关键因素是对软件工程师、他们的经理和其他利益相关者的教育。SQA 组织在软件过程改进方面处于领先地位(第 28 章),并且是教育计划的主要支持者和赞助者。

  • Education. Every software organization wants to improve its software engineering practices. A key contributor to improvement is education of software engineers, their managers, and other stakeholders. The SQA organization takes the lead in software process improvement (Chapter 28) and is a key proponent and sponsor of educational programs.

  • 供应商管理。从外部软件供应商处获取三类软件——收缩包装包(例如 Microsoft Office)、定制外壳[Hor03](提供根据购买者需求定制的基本骨架结构)以及合同软件根据客户组织提供的规格进行定制设计和构造。SQA 组织的工作是通过建议供应商应遵循的具体质量实践(如果可能)并将质量要求纳入与外部供应商的任何合同的一部分,以确保获得高质量的软件结果。

  • Vendor management. Three categories of software are acquired from external software vendors—shrink-wrapped packages (e.g., Microsoft Office), a tailored shell [Hor03] that provides a basic skeletal structure that is custom tailored to the needs of a purchaser, and contracted software that is custom designed and constructed from specifications provided by the customer organization. The job of the SQA organization is to ensure that high-quality software results by suggesting specific quality practices that the vendor should follow (when possible) and incorporating quality mandates as part of any contract with an external vendor.

  • 安全管理。随着网络犯罪的增加和政府对隐私的新规定,每个软件组织都应该制定保护各级数据的政策,为移动应用程序建立防火墙保护,并确保软件不被内部篡改。SQA 确保使用适当的流程和技术来实现软件安全(第 18 章)。

  • Security management. With the increase in cyber crime and new government regulations regarding privacy, every software organization should institute policies that protect data at all levels, establish firewall protection for mobile apps, and ensure that software has not been tampered with internally. SQA ensures that appropriate process and technology are used to achieve software security (Chapter 18).

  • 安全。由于软件几乎总是人类评级系统(例如汽车或飞机应用)的关键组件,因此隐藏缺陷的影响可能是灾难性的。SQA 可能负责评估软件故障的影响并启动降低风险所需的步骤。

  • Safety. Because software is almost always a pivotal component of human-rated systems (e.g., automotive or aircraft applications), the impact of hidden defects can be catastrophic. SQA may be responsible for assessing the impact of software failure and for initiating those steps required to reduce risk.

  • 风险管理。尽管风险分析和缓解(第 26 章)是软件工程师关心的问题,但 SQA 组织确保风险管理活动得到正确执行,并建立与风险相关的应急计划。

  • Risk management. Although the analysis and mitigation of risk (Chapter 26) is the concern of software engineers, the SQA organization ensures that risk management activities are properly conducted and that risk-related contingency plans have been established.

第343页除了这些关注点和活动之外,SQA 还致力于确保软件支持活动(例如,维护、帮助热线、文档和手册)的实施或生产以质量为主要关注点。

Page 343In addition to each of these concerns and activities, SQA works to ensure that software support activities (e.g., maintenance, help lines, documentation, and manuals) are conducted or produced with quality as a dominant concern.

17.3 SQA 流程和产品特性

17.3 SQA Processes and Product Characteristics

当我们开始讨论软件质量保证时,需要注意的是,在一种软件环境中有效的 SQA 程序和方法在另一种软件环境中可能效果不佳。即使在采用一致的软件工程方法2的公司内,不同的软件产品也可能表现出不同的质量水平 [Par11]。

As we begin a discussion of software quality assurance, it’s important to note that SQA procedures and approaches that work in one software environment may not work as well in another. Even within a company that adopts a consistent approach2 to software engineering, different software products may exhibit different levels of quality [Par11].

解决这一困境的方法是了解软件产品的特定质量要求,然后选择用于满足这些要求的流程以及特定的 SQA 操作和任务。软件工程学院的 CMMI 和 ISO 9000 标准是最常用的过程框架。每个都提出了“语法和语义”[Par11],这将导致实施提高产品质量的软件工程实践。软件组织可以通过选择两个框架的元素并将其与单个产品的质量要求相匹配来“协调”这两个模型,而不是整体实例化任一框架。

The solution to this dilemma is to understand the specific quality requirements for a software product and then select the process and specific SQA actions and tasks that will be used to meet those requirements. The Software Engineering Institute’s CMMI and ISO 9000 standards are the most commonly used process frameworks. Each proposes “a syntax and semantics” [Par11] that will lead to the implementation of software engineering practices that improve product quality. Rather than instantiating either framework in its entirety, a software organization can “harmonize” the two models by selecting elements of both frameworks and matching them to the quality requirements of an individual product.

17.4 SQA 任务、目标和指标

17.4 SQA Tasks, Goals, and Metrics

软件质量保证由与两个不同部门相关的各种任务组成:从事技术工作的软件工程师和负责质量保证规划、监督、记录保存、分析和报告的 SQA 小组。

Software quality assurance is composed of a variety of tasks associated with two different constituencies—the software engineers who do technical work and an SQA group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting.

现代软件质量保证通常是数据驱动的,如图17.2所示。产品利益相关者定义目标和质量措施,识别问题领域,测量指标,并确定是否需要流程变更。软件工程师通过应用可靠的技术方法和措施、进行技术审查以及执行精心计划的软件测试来解决质量问题(并执行质量控制活动)。

Modern software quality assurance is often data driven, as shown in Figure 17.2. The product stakeholders define goals and quality measures, problem areas are identified, indicators are measured, and a determination is made as to whether or not process changes are needed. Software engineers address quality (and perform quality control activities) by applying solid technical methods and measures, conducting technical reviews, and performing well-planned software testing.

图17.2 软件质量保证

Figure 17.2 Software quality assurance

17.4.1 SQA任务

17.4.1 SQA Tasks

SQA 小组的职责是协助软件团队实现高质量的最终产品。软件工程学院推荐了一套 SQA 活动,用于解决质量保证规划、监督、记录保存、分析和报告问题。这些活动由独立的 SQA 小组执行(或协助),该小组:

The charter of the SQA group is to assist the software team in achieving a high-quality end product. The Software Engineering Institute recommends a set of SQA activities that address quality assurance planning, oversight, record keeping, analysis, and reporting. These activities are performed (or facilitated) by an independent SQA group that:

  • 为项目准备 SQA 计划。该计划作为项目规划的一部分制定,并由所有利益相关者审查。软件工程团队和 SQA 小组执行的质量保证活动受该计划管辖。该计划确定了要执行的评估、要进行的审计和评审、适用于项目的标准、错误报告和跟踪程序、SQA 小组生成的工作产品以及将提供给软件团队的反馈。第344页

  • Prepares an SQA plan for a project. The plan is developed as part of project planning and is reviewed by all stakeholders. Quality assurance activities performed by the software engineering team and the SQA group are governed by the plan. The plan identifies evaluations to be performed, audits and reviews to be conducted, standards that are applicable to the project, procedures for error reporting and tracking, work products that are produced by the SQA group, and feedback that will be provided to the software team.Page 344

  • 参与项目软件流程描述的开发。软件团队选择要执行的工作的流程。SQA 小组审查流程描述是否符合组织政策、内部软件标准、外部强加的标准(例如 ISO-9001)以及软件项目计划的其他部分。

  • Participates in the development of the project’s software process description. The software team selects a process for the work to be performed. The SQA group reviews the process description for compliance with organizational policy, internal software standards, externally imposed standards (e.g., ISO-9001), and other parts of the software project plan.

  • 审查软件工程活动以验证是否符合定义的软件流程。SQA 小组识别、记录和跟踪流程中的偏差,并验证是否已进行纠正。

  • Reviews software engineering activities to verify compliance with the defined software process. The SQA group identifies, documents, and tracks deviations from the process and verifies that corrections have been made.

  • 审核指定的软件工作产品,以验证其是否符合软件流程中定义的产品。SQA 小组审查选定的工作产品;识别、记录和跟踪偏差;验证是否已进行更正;并定期向项目经理汇报工作结果。

  • Audits designated software work products to verify compliance with those defined as part of the software process. The SQA group reviews selected work products; identifies, documents, and tracks deviations; verifies that corrections have been made; and periodically reports the results of its work to the project manager.

  • 确保软件工作和工作产品中的偏差被记录下来并根据记录的程序进行处理。项目计划、过程描述、适用标准或软件工程工作产品中可能会遇到偏差。

  • Ensures that deviations in software work and work products are documented and handled according to a documented procedure. Deviations may be encountered in the project plan, process description, applicable standards, or software engineering work products.

  • 记录任何不合规情况,并向高级管理层报告。不合规项目将被跟踪直至解决。

  • Records any noncompliance, and reports to senior management. Noncompliance items are tracked until they are resolved.

除了这些活动之外,SQA 小组还协调变更的控制和管理(第 22 章)并帮助收集和分析软件指标。第345页

In addition to these activities, the SQA group coordinates the control and management of change (Chapter 22) and helps to collect and analyze software metrics.Page 345

17.4.2 目标、属性和指标

17.4.2 Goals, Attributes, and Metrics

执行上一节中描述的 SQA 活动是为了实现一组务实的目标:

The SQA activities described in the preceding section are performed to achieve a set of pragmatic goals:

  • 要求品质。需求模型的正确性、完整性和一致性将对后续所有工作产品的质量产生重大影响。SQA 必须确保软件团队正确审查了需求模型,以实现高水平的质量。

  • Requirements quality. The correctness, completeness, and consistency of the requirements model will have a strong influence on the quality of all work products that follow. SQA must ensure that the software team has properly reviewed the requirements model to achieve a high level of quality.

  • 设计品质。设计模型的每个元素都应由软件团队进行评估,以确保其具有高质量并且设计本身符合要求。SQA 寻找作为质量指标的设计属性。

  • Design quality. Every element of the design model should be assessed by the software team to ensure that it exhibits high quality and that the design itself conforms to requirements. SQA looks for attributes of the design that are indicators of quality.

  • 代码质量。源代码和相关工作产品(例如其他描述性信息)必须符合当地编码标准并表现出有利于可维护性的特征。SQA 应该隔离那些允许对代码质量进行合理分析的属性。

  • Code quality. Source code and related work products (e.g., other descriptive information) must conform to local coding standards and exhibit characteristics that will facilitate maintainability. SQA should isolate those attributes that allow a reasonable analysis of the quality of code.

  • 第346页质量控制有效性。软件团队应该以最有可能实现高质量结果的方式应用有限的资源。SQA 分析用于审查和测试的资源分配,以评估它们是否以最有效的方式分配。

  • Page 346Quality control effectiveness. A software team should apply limited resources in a way that has the highest likelihood of achieving a high-quality result. SQA analyzes the allocation of resources for reviews and testing to assess whether they are being allocated in the most effective manner.

表 17.1(改编自 [Hya96])标识了作为所讨论的每个目标的质量存在指标的属性。还显示了可用于指示属性的相对强度的指标。

Table 17.1 (adapted from [Hya96]) identifies the attributes that are indicators for the existence of quality for each of the goals discussed. Metrics that can be used to indicate the relative strength of an attribute are also shown.

资料来源:改编自 Hyatt, L. 和 Rosenberg, L.,“用于识别项目风险和评估软件质量的软件质量模型和指标”,NASA SATC,1996 年。

Source: Adapted from Hyatt, L., and Rosenberg, L., “A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality,” NASA SATC, 1996.

第347页

Page 347

17.5 SQA 的正式方法

17.5 Formal Approaches to SQA

在前面的章节中,我们认为软件质量是每个人的工作,它可以通过合格的软件工程实践以及技术审查的应用、多层测试策略、更好地控制软件工作产品和所做的更改来实现。以及公认的软件工程标准和过程框架的应用。此外,质量可以根据广泛的质量属性来定义,并使用各种指数和指标来测量(间接)。

In the preceding sections, we have argued that software quality is everyone’s job and that it can be achieved through competent software engineering practice as well as through the application of technical reviews, a multitiered testing strategy, better control of software work products and the changes made to them, and the application of accepted software engineering standards and process frameworks. In addition, quality can be defined in terms of a broad array of quality attributes and measured (indirectly) using a variety of indices and metrics.

在过去的三十年里,软件工程社区中一小部分但直言不讳的人认为,需要一种更正式的软件质量保证方法。可以说计算机程序是一个数学对象。可以为每种编程语言定义严格的语法和语义,并且可以使用严格的方法来规范软件需求。如果需求模型(规范)和编程语言可以以严格的方式表示,则应该可以应用正确性的数学证明来证明程序完全符合其规范。

Over the past three decades, a small, but vocal, segment of the software engineering community has argued that a more formal approach to software quality assurance is required. It can be argued that a computer program is a mathematical object. A rigorous syntax and semantics can be defined for every programming language, and a rigorous approach to the specification of software requirements is available. If the requirements model (specification) and the programming language can be represented in a rigorous manner, it should be possible to apply mathematic proof of correctness to demonstrate that a program conforms exactly to its specifications.

证明程序正确性的尝试并不新鲜。Dijkstra [Dij76a] 和 Linger、Mills 和 Witt [Lin79] 等人提倡程序正确性的证明,并将其与结构化编程概念的使用联系起来。尽管一些软件工程研究人员对形式化方法很感兴趣,但商业开发人员在 2018 年很少使用形式化方法。

Attempts to prove programs correct are not new. Dijkstra [Dij76a] and Linger, Mills, and Witt [Lin79], among others, advocated proofs of program correctness and tied these to the use of structured programming concepts. Although formal methods are interesting to some software engineering researchers, commercial developers rarely make use of formal methods in 2018.

17.6 统计软件质量保证

17.6 Statistical Software Quality Assurance

统计质量保证反映了整个行业对质量更加量化的趋势。对于软件来说,统计质量保证意味着以下步骤:

Statistical quality assurance reflects a growing trend throughout the industry to become more quantitative about quality. For software, statistical quality assurance implies the following steps:

  1. 有关软件错误和缺陷的信息被收集并分类。

  2. Information about software errors and defects is collected and categorized.

  3. 我们尝试追踪每个错误和缺陷的根本原因(例如,不符合规范、设计错误、违反标准、与客户沟通不畅)。

  4. An attempt is made to trace each error and defect to its underlying cause (e.g., nonconformance to specifications, design error, violation of standards, poor communication with the customer).

  5. 使用帕累托原理(80% 的缺陷可以追溯到所有可能原因中的 20%),隔离 20%(至关重要的少数)。

  6. Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible causes), isolate the 20 percent (the vital few).

  7. 一旦确定了几个重要的原因,就开始纠正导致错误和缺陷的问题。

  8. Once the vital few causes have been identified, move to correct the problems that have caused the errors and defects.

这个相对简单的概念代表了创建自适应软件过程的重要一步,在该过程中进行更改以改进过程中引入错误的那些元素。

This relatively simple concept represents an important step toward the creation of an adaptive software process in which changes are made to improve those elements of the process that introduce error.

17.6.1 一个通用示例

17.6.1 A Generic Example

为了说明统计方法在软件工程工作中的使用,假设软件工程组织收集了为期 1 年的错误和缺陷信息。有些错误是在软件开发过程中被发现的。在软件发布给最终用户后,还会遇到其他缺陷。尽管发现了数百个不同的问题,但所有问题都可以追溯到以下一个(或多个)原因:第348页

To illustrate the use of statistical methods for software engineering work, assume that a software engineering organization collects information on errors and defects for a period of 1 year. Some of the errors are uncovered as software is being developed. Other defects are encountered after the software has been released to its end users. Although hundreds of different problems are uncovered, all can be tracked to one (or more) of the following causes:Page 348

  • 不完整或错误的规格 (IES)

  • Incomplete or erroneous specifications (IES)

  • 对客户沟通的误解 (MCC)

  • Misinterpretation of customer communication (MCC)

  • 故意偏离规格 (IDS)

  • Intentional deviation from specifications (IDS)

  • 违反编程标准 (VPS)

  • Violation of programming standards (VPS)

  • 数据表示错误 (EDR)

  • Error in data representation (EDR)

  • 组件接口不一致 (ICI)

  • Inconsistent component interface (ICI)

  • 设计逻辑错误 (EDL)

  • Error in design logic (EDL)

  • 不完整或错误的测试 (IET)

  • Incomplete or erroneous testing (IET)

  • 文档不准确或不完整 (IID)

  • Inaccurate or incomplete documentation (IID)

  • 设计的编程语言翻译 (PLT) 错误

  • Error in programming language translation of design (PLT)

  • 不明确或不一致的人机界面 (HCI)

  • Ambiguous or inconsistent human/computer interface (HCI)

  • 杂项(管理信息系统)

  • Miscellaneous (MIS)

为了应用统计 SQA,建立了一个表(参见表17.2)。该表表明 IES、MCC 和 EDR 是占所有错误 53% 的少数重要原因。但需要注意的是,如果只考虑严重错误,将选择IES、EDR、PLT和EDL作为重要的少数原因。一旦确定了几个重要的原因,软件工程组织就可以开始采取纠正措施。例如,为了纠正 MCC,您可以实施需求收集技术(第 7 章)来提高客户沟通和规范的质量。为了改进 EDR,您可以获取数据建模工具并执行更严格的数据设计审查。

To apply statistical SQA, a table is built (see Table 17.2). The table indicates that IES, MCC, and EDR are the vital few causes that account for 53 percent of all errors. It should be noted, however, that IES, EDR, PLT, and EDL would be selected as the vital few causes if only serious errors are considered. Once the vital few causes are determined, the software engineering organization can begin corrective action. For example, to correct MCC, you might implement requirements gathering techniques (Chapter 7) to improve the quality of customer communication and specifications. To improve EDR, you might acquire tools for data modeling and perform more stringent data design reviews.

第349页值得注意的是,纠正措施主要针对少数至关重要的人。当几个重要的原因得到纠正后,新的候选人就会出现在堆栈的顶部。

Page 349It is important to note that corrective action focuses primarily on the vital few. As the vital few causes are corrected, new candidates pop to the top of the stack.

软件的统计质量保证技术已被证明可以提供实质性的质量改进(例如,[Rya11]、[Art97])。在某些情况下,应用这些技术后,软件组织的缺陷每年减少 50%。

Statistical quality assurance techniques for software have been shown to provide substantial quality improvement (e.g., [Rya11], [Art97]). In some cases, software organizations have achieved a 50 percent reduction per year in defects after applying these techniques.

统计 SQA 和帕累托原理的应用可以用一句话来概括:把时间花在真正重要的事情上,但首先要确保你了解真正重要的事情!

The application of the statistical SQA and the Pareto principle can be summarized in a single sentence: Spend your time focusing on things that really matter, but first be sure that you understand what really matters!

17.6.2 软件工程的六西格码

17.6.2 Six Sigma for Software Engineering

六西格码是当今行业中使用最广泛的统计质量保证策略。六西格码战略最初由摩托罗拉在 20 世纪 80 年代推广,“是一种业务管理战略,旨在通过最大限度地减少流程中的变化和缺陷原因来提高流程输出的质量。它是全面质量管理 (TQM) 方法的一个子集,重点关注用于降低成本和提高质量的统计应用”[Voe18]。术语“六西格码”源自六个标准差——每百万次事件中有 3.4 个实例(缺陷)——意味着极高的质量标准。六西格码方法定义了三个核心步骤:

Six Sigma is the most widely used strategy for statistical quality assurance in industry today. Originally popularized by Motorola in the 1980s, the Six Sigma strategy “is a business-management strategy designed to improve the quality of process outputs by minimizing variation and causes of defects in processes. It is a subset of the Total Quality Management (TQM) methodology with a heavy focus on statistical applications used to reduce costs and improve quality” [Voe18]. The term Six Sigma is derived from six standard deviations—3.4 instances (defects) per million occurrences—implying an extremely high-quality standard. The Six Sigma methodology defines three core steps:

  • 通过明确的客户沟通方法来定义客户需求和可交付成果以及项目目标。

  • Define customer requirements and deliverables and project goals via well-defined methods of customer communication.

  • 测量现有流程及其输出以确定当前的质量绩效(收集缺陷指标)。

  • Measure the existing process and its output to determine current quality performance (collect defect metrics).

  • 分析缺陷指标并确定几个重要的原因。

  • Analyze defect metrics and determine the vital few causes.

如果现有软件流程已到位,但需要改进,六西格码建议采取两个额外步骤:

If an existing software process is in place, but improvement is required, Six Sigma suggests two additional steps:

  • 通过消除缺陷的根本原因来改进流程。

  • Improve the process by eliminating the root causes of defects.

  • 控制过程以确保未来的工作不会再次引入缺陷的原因。

  • Control the process to ensure that future work does not reintroduce the causes of defects.

这些核心步骤和附加步骤有时称为 DMAIC(定义、测量、分析、改进和控制)方法。

These core and additional steps are sometimes referred to as the DMAIC (define, measure, analyze, improve, and control) method.

如果组织正在开发软件流程(而不是改进现有流程),则核心步骤将增加如下:

If an organization is developing a software process (rather than improving an existing process), the core steps are augmented as follows:

  • 设计流程的目的是 (1) 避免缺陷的根本原因,以及 (2) 满足客户的要求。

  • Design the process to (1) avoid the root causes of defects and (2) to meet customer requirements.

  • 验证流程模型实际上可以避免缺陷并满足客户要求。

  • Verify that the process model will, in fact, avoid defects and meet customer requirements.

这种变化有时称为 DMADV(定义、测量、分析、设计和验证)方法。

This variation is sometimes called the DMADV (define, measure, analyze, design, and verify) method.

对六西格码的全面讨论最好留给专门用于该主题的资源。如果您有进一步的兴趣,请参阅 [Voe18]、[Pyz14] 和 [Sne18]。

A comprehensive discussion of Six Sigma is best left to resources dedicated to the subject. If you have further interest, see [Voe18], [Pyz14], and [Sne18].

第350页

Page 350

17.7 软件可靠性

17.7 Software Reliability

毫无疑问,计算机程序的可靠性是其整体质量的重要因素。如果一个程序反复且频繁地无法执行,那么其他软件质量因素是否可接受就无关紧要了。

There is no doubt that the reliability of a computer program is an important element of its overall quality. If a program repeatedly and frequently fails to perform, it matters little whether other software quality factors are acceptable.

与许多其他质量因素不同,软件可靠性可以直接测量并使用历史和开发数据进行估计。软件可靠性在统计术语中被定义为“计算机程序在指定环境下指定时间内无故障运行的概率”[Mus87]。为了说明这一点,程序X在过去的 8 个小时内的可靠性估计为 0.999。换句话说,如果程序X要执行1000次并且需要总共8小时的经过处理时间(执行时间),则它可能正确运行(无故障)999次。

Software reliability, unlike many other quality factors, can be measured directly and estimated using historical and developmental data. Software reliability is defined in statistical terms as “the probability of failure-free operation of a computer program in a specified environment for a specified time” [Mus87]. To illustrate, program X is estimated to have a reliability of 0.999 over eight elapsed processing hours. In other words, if program X were to be executed 1000 times and require a total of 8 hours of elapsed processing time (execution time), it is likely to operate correctly (without failure) 999 times.

每当讨论软件可靠性时,就会出现一个关键问题:术语“故障”是什么意思?在任何有关软件质量和可靠性的讨论中,失败都是不符合软件需求的情况。然而,即使在这个定义内,也存在等级。失败只会令人烦恼或灾难性的。一种故障可以在几秒钟内纠正,而另一种故障则需要数周甚至数月才能纠正。使问题更加复杂的是,纠正一个故障实际上可能会导致引入其他错误,最终导致其他故障。

Whenever software reliability is discussed, a pivotal question arises: What is meant by the term failure? In the context of any discussion of software quality and reliability, failure is nonconformance to software requirements. Yet, even within this definition, there are gradations. Failures can be only annoying or catastrophic. One failure can be corrected within seconds, while another requires weeks or even months to correct. Complicating the issue even further, the correction of one failure may in fact result in the introduction of other errors that ultimately result in other failures.

17.7.1 可靠性和可用性的测量

17.7.1 Measures of Reliability and Availability

软件可靠性的早期工作试图将硬件可靠性理论的数学外推到软件可靠性的预测。大多数与硬件相关的可靠性模型都是基于磨损引起的故障而不是设计缺陷引起的故障。在硬件中,由于物理磨损(例如,温度、腐蚀、冲击的影响)而导致的故障比与设计相关的故障更有可能。不幸的是,软件的情况恰恰相反。事实上,所有软件故障都可以追溯到设计或实现问题;磨损(参见第 1 章)不是一个因素。

Early work in software reliability attempted to extrapolate the mathematics of hardware reliability theory to the prediction of software reliability. Most hardware-related reliability models are predicated on failure due to wear rather than failure due to design defects. In hardware, failures due to physical wear (e.g., the effects of temperature, corrosion, shock) are more likely than a design-related failure. Unfortunately, the opposite is true for software. In fact, all software failures can be traced to design or implementation problems; wear (see Chapter 1) is not a factor.

关于硬件可靠性的关键概念与其对软件的适用性之间的关系一直存在争论。尽管尚未建立无可辩驳的联系,但值得考虑一些适用于这两个系统元素的简单概念。

There has been an ongoing debate over the relationship between key concepts in hardware reliability and their applicability to software. Although an irrefutable link has yet to be established, it is worthwhile to consider a few simple concepts that apply to both system elements.

如果我们考虑基于计算机的系统,可靠性的一个简单衡量标准是平均故障间隔时间(MTBF):3

If we consider a computer-based system, a simple measure of reliability is mean time between failure (MTBF):3

平均无故障时间 = 平均故障时间 + 平均修复时间

MTBF = MTTF + MTTR

其中缩写词 MTTF 和 MTTR 分别是平均无故障时间平均修复时间4

where the acronyms MTTF and MTTR are mean time to failure and mean time to repair,4 respectively.

第351页许多研究人员认为,MTBF 比第 23 章中讨论的其他与质量相关的软件指标更有用。简而言之,最终用户关心的是故障,而不是缺陷总数。由于程序中包含的每个缺陷不具有相同的故障率,因此总缺陷数几乎无法表明系统的可靠性。例如,考虑一个程序已经运行了 3000 个处理器小时而没有出现故障。该程序中的许多缺陷可能在被发现之前数万小时都未被发现。此类模糊错误的 MTBF 可能是 30,000 甚至 60,000 个处理器小时。其他尚未发现的缺陷可能会有 4000 或 5000 小时的故障率。即使第一类错误(MTBF 较长的错误)中的每一个都被消除,对软件可靠性的影响也可以忽略不计。

Page 351Many researchers argue that MTBF is a far more useful measure than other quality-related software metrics discussed in Chapter 23. Stated simply, an end user is concerned with failures, not with the total defect count. Because each defect contained within a program does not have the same failure rate, the total defect count provides little indication of the reliability of a system. For example, consider a program that has been in operation for 3000 processor hours without failure. Many defects in this program may remain undetected for tens of thousands of hours before they are discovered. The MTBF of such obscure errors might be 30,000 or even 60,000 processor hours. Other defects, not yet discovered, might have a failure rate of 4000 or 5000 hours. Even if every one of the first category of errors (those with long MTBF) is removed, the impact on software reliability is negligible.

然而,MTBF 可能存在问题,原因有二:(1) 它预测了故障之间的时间跨度,但没有为我们提供预测的故障率;(2) MTBF 可能会被误解为平均寿命,尽管这并不是真正的平均寿命。它意味着。

However, MTBF can be problematic for two reasons: (1) it projects a time span between failures but does not provide us with a projected failure rate, and (2) MTBF can be misinterpreted to mean average life span even though this is not what it implies.

可靠性的另一种衡量标准是故障及时率(FIT),这是一种统计衡量指标,用于衡量组件在超过 10 亿小时的运行时间内出现故障的次数。因此,1 FIT 相当于每 10 亿小时运行就有 1 次故障。

An alternative measure of reliability is failures in time (FIT)—a statistical measure of how many failures a component will have over 1 billion hours of operation. Therefore, 1 FIT is equivalent to one failure in every billion hours of operation.

除了可靠性度量之外,您还应该制定可用性度量。软件可用性是指程序在给定时间点按照要求运行的概率,定义为

In addition to a reliability measure, you should also develop a measure of availability. Software availability is the probability that a program is operating according to requirements at a given point in time and is defined as

MTBF 可靠性测量对 MTTF 和 MTTR 同样敏感。可用性度量对 MTTR 更敏感,MTTR 是软件可维护性的间接度量。当然,可用性的某些方面与故障无关。例如,安排停机时间(用于支持功能)会导致软件不可用。有关软件可靠性度量的全面讨论,请参阅 [Laz11]。

The MTBF reliability measure is equally sensitive to MTTF and MTTR. The availability measure is somewhat more sensitive to MTTR, an indirect measure of the maintainability of software. Of course, some aspects of availability have nothing to do with failure. For example, scheduling downtime (for support functions) causes the software to be unavailable. For a comprehensive discussion of software reliability measures, see [Laz11].

17.7.2 使用人工智能进行可靠性建模

17.7.2 Use of AI to Model Reliability

一些软件工程师将数据科学视为人工智能技术解决软件工程问题的应用。人工智能方法试图做的事情之一是为所需数据可能不完整的问题提供合理的解决方案。软件可靠性定义为软件在指定环境下、指定时间段内无故障运行的概率。这意味着我们永远无法知道软件产品失败的确切时刻,因为我们永远不会拥有计算概率所需的完整数据。

Some software engineers view data science as the application of artificial intelligence techniques to solve software engineering problems. One of the things artificial intelligence methods attempt to do is provide reasonable solutions to problems where the needed data may be incomplete. Software reliability is defined as the probability of failure-free software operation for a specified time period in a specified environment. This means that we can never know the exact moment when a software product will fail because we will never have the complete data needed to calculate the probability.

软件工程师多年来一直在定量决策情况下使用基于贝叶斯定理5的统计技术。贝叶斯推理是一种统计推理方法,其中贝叶斯定理用于随着更多证据或信息的出现而更新假设的概率(例如系统可靠性)。即使某些信息缺失,贝叶斯推理也可用于使用历史数据来估计概率量。使用贝叶斯技术可以实时解决超出人类推理范围的概率估计问题 [Tos17]。第352页

Software engineers have used statistical techniques based on Bayes’ theorem5 in quantitative decision-making situations for several years. Bayesian inference is a method of statistical inference in which Bayes’ theorem is used to update the probability for a hypothesis (such as system reliability) as more evidence or information becomes available. Bayesian inference can be used to estimate probabilistic quantities using historic data even when some information is missing. Using Bayesian techniques has allowed for real-time solutions to probability estimation problems that are beyond human reasoning [Tos17].Page 352

第 15.4.3 节简要讨论了使用机器学习的主动故障预测。在交付当前冲刺中正在开发的原型之前,如果能够预测后续冲刺中的系统故障,那就太好了。利用预测数据分析(例如涉及 MTBF 的回归模型)来估计未来原型中可能出现的缺陷位置和类型 [Bat18]。

Proactive failure prediction using machine learning was discussed briefly in Section 15.4.3. It would be nice to be able to predict system failures in subsequent sprints before you deliver the prototype being developed in the current sprint. Making use of predictive data analytics such as a regression model involving MTBF has been used to estimate where and what types of defects might occur in future prototypes [Bat18].

遗传算法是一种用于人工智能和计算的启发式搜索方法。它用于基于自然选择和进化生物学理论寻找搜索问题的近乎最佳解决方案。遗传算法可用于通过发现历史系统数据中的关系来发展可靠性模型。这些模型已用于识别未来可能出现故障的软件组件。有时,在编写任何代码之前,这些模型是根据 UML 模型估计的指标创建的 [Pad17]。这类工作对于有兴趣重构软件产品或在其他产品中重用软件组件的开发人员来说非常重要。

A genetic algorithm is a heuristic search method used in artificial intelligence and computing. It is used for finding near-optimal solutions to search problems based on the theory of natural selection and evolutionary biology. Genetic algorithms can be used to grow reliability models by discovering relationships in historic system data. These models have been used to identify software components that may fail in the future. Sometimes these models have been created based on metrics estimated from UML models before any codes has been written [Pad17]. This type of work is very important to developers interested in refactoring software products or reusing software components in other products.

17.7.3 软件安全

17.7.3 Software Safety

软件安全是一项软件质量保证活动,重点是识别和评估可能对软件产生负面影响并导致整个系统失败的潜在危险。如果可以在软件过程的早期识别危险,则可以指定软件设计功能来消除或控制潜在危险。

Software safety is a software quality assurance activity that focuses on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If hazards can be identified early in the software process, software design features can be specified that will either eliminate or control potential hazards.

建模和分析过程是作为软件安全的一部分进行的。首先,根据严重性和风险来识别危险并进行分类。例如,与基于计算机的汽车巡航控制系统相关的一些危险可能是:(1) 导致无法停止的不受控制的加速,(2) 对踩下制动踏板(通过关闭)没有反应,( 3) 当开关被激活时不接合,并且 (4) 缓慢地失去或增加速度。一旦识别出这些系统级危险,就可以使用分析技术来确定严重性和发生概率。6为了有效,必须在整个系统的背景下对软件进行分析。例如,细微的用户输入错误(人是系统组件)可能会因软件故障而放大,从而产生不正确定位机械设备的控制数据。当且仅当满足一组外部环境条件时,机械装置的不当位置才会导致灾难性的故障。故障树分析、实时逻辑和 Petri 网模型等分析技术 [Eri15] 可用于预测可能导致危险的事件链以及每个事件发生以创建该链的概率。

A modeling and analysis process is conducted as part of software safety. Initially, hazards are identified and categorized by criticality and risk. For example, some of the hazards associated with a computer-based cruise control for an automobile might be: (1) causes uncontrolled acceleration that cannot be stopped, (2) does not respond to depression of brake pedal (by turning off), (3) does not engage when switch is activated, and (4) slowly loses or gains speed. Once these system-level hazards are identified, analysis techniques are used to assign severity and probability of occurrence.6 To be effective, software must be analyzed in the context of the entire system. For example, a subtle user input error (people are system components) may be magnified by a software fault to produce control data that improperly positions a mechanical device. If and only if a set of external environmental conditions is met, the improper position of the mechanical device will cause a disastrous failure. Analysis techniques [Eri15] such as fault tree analysis, real-time logic, and Petri net models can be used to predict the chain of events that can cause hazards and the probability that each of the events will occur to create the chain.

第353页一旦识别和分析了危险,就可以为软件指定安全相关的要求。也就是说,规范可以包含不期望事件的列表以及对这些事件的期望系统响应。然后指出了软件在管理不良事件中的作用。

Page 353Once hazards are identified and analyzed, safety-related requirements can be specified for the software. That is, the specification can contain a list of undesirable events and the desired system responses to these events. The role of software in managing undesirable events is then indicated.

尽管软件可靠性和软件安全性彼此相关,但了解它们之间的细微差别也很重要。软件可靠性使用统计分析来确定软件故障发生的可能性。然而,故障的发生并不一定会导致危险或事故。软件安全检查故障导致可能导致事故的情况的方式。也就是说,故障不是在真空中考虑的,而是在整个基于计算机的系统及其环境的背景下进行评估的。

Although software reliability and software safety are related to one another, it is important to understand the subtle difference between them. Software reliability uses statistical analysis to determine the likelihood that a software failure will occur. However, the occurrence of a failure does not necessarily result in a hazard or mishap. Software safety examines the ways in which failures result in conditions that can lead to a mishap. That is, failures are not considered in a vacuum but are evaluated in the context of an entire computer-based system and its environment.

对软件安全性的全面讨论超出了本书的范围。如果您对软件安全和相关系统问题有进一步的兴趣,请参阅 [Fir13]、[Har12a] 和 [Lev12]。

A comprehensive discussion of software safety is beyond the scope of this book. If you have further interest in software safety and related system issues, see [Fir13], [Har12a], and [Lev12].

17.8 ISO 9000 质量标准7

17.8 The ISO 9000 Quality Standards7

质量保证体系可以定义为实施质量管理的组织结构、职责、程序、流程和资源[ANS87]。创建质量保证体系是为了帮助组织确保其产品和服务满足客户的规格,从而满足客户的期望。这些系统涵盖涵盖产品整个生命周期的各种活动,包括规划、控制、测量、测试和报告,以及提高整个开发和制造过程的质量水平。ISO 9000 用通用术语描述了质量保证要素,可以应用于任何企业,无论提供什么产品或服务。

A quality assurance system may be defined as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management [ANS87]. Quality assurance systems are created to help organizations ensure their products and services satisfy customer expectations by meeting their specifications. These systems cover a wide variety of activities encompassing a product’s entire life cycle including planning, controlling, measuring, testing, and reporting, and improving quality levels throughout the development and manufacturing process. ISO 9000 describes quality assurance elements in generic terms that can be applied to any business regardless of the products or services offered.

为了注册 ISO 9000 中包含的质量保证体系模型之一,公司的质量体系和运营需要由第三方审核员进行审查,以确保其符合标准并有效运行。成功注册后,公司将获得由审核员代表的注册机构颁发的证书。半年一次的监督审核确保持续符合标准。

To become registered to one of the quality assurance system models contained in ISO 9000, a company’s quality system and operations are scrutinized by third-party auditors for compliance to the standard and for effective operation. Upon successful registration, a company is issued a certificate from a registration body represented by the auditors. Semiannual surveillance audits ensure continued compliance to the standard.

ISO 9001:2015 规定的要求涉及管理责任、质量体系、合同审查、设计控制、文件和数据控制、产品识别和可追溯性、过程控制、检验和测试、纠正和预防措施、质量记录控制等主题、内部质量审核、培训、服务和统计技术。对于要注册 ISO 9001:2015 的软件组织,它必须制定政策和程序来满足刚才提到的每项要求(以及其他要求),然后能够证明这些政策和程序得到遵守。如果您需要有关 ISO 9001:2015 的更多信息,请参阅 [ISO14]。第354页

The requirements delineated by ISO 9001:2015 address topics such as management responsibility, quality system, contract review, design control, document and data control, product identification and traceability, process control, inspection and testing, corrective and preventive action, control of quality records, internal quality audits, training, servicing, and statistical techniques. For a software organization to become registered to ISO 9001:2015, it must establish policies and procedures to address each of the requirements just noted (and others) and then be able to demonstrate that these policies and procedures are being followed. If you desire further information on ISO 9001:2015, see [ISO14].Page 354

17.9 SQA 计划

17.9 The SQA Plan

SQA 计划提供了建立软件质量保证的路线图。该计划由 SQA 小组(如果不存在 SQA 小组,则由软件团队)制定,充当为每个软件项目制定的 SQA 活动的模板。

The SQA plan provides a road map for instituting software quality assurance. Developed by the SQA group (or by the software team if an SQA group does not exist), the plan serves as a template for SQA activities that are instituted for each software project.

IEEE [IEE17] 已发布 SQA 计划标准。该标准建议采用一种结构来识别:(1) 计划的目的和范围,(2) 对属于 SQA 范围内的所有软件工程工作产品(例如模型、文档、源代码)的描述,(3 )软件过程中应用的所有适用标准和实践,(4)SQA 行动和任务(包括评审和审计)及其在整个软件过程中的位置,(5)支持 SQA 行动和任务的工具和方法,( 6)软件配置管理(第22章)程序,(7)组装、保护和维护所有SQA相关记录的方法,以及(8)与产品质量相关的组织角色和职责。

A standard for SQA plans has been published by the IEEE [IEE17]. The standard recommends a structure that identifies: (1) the purpose and scope of the plan, (2) a description of all software engineering work products (e.g., models, documents, source code) that fall within the purview of SQA, (3) all applicable standards and practices that are applied during the software process, (4) SQA actions and tasks (including reviews and audits) and their placement throughout the software process, (5) the tools and methods that support SQA actions and tasks, (6) software configuration management (Chapter 22) procedures, (7) methods for assembling, safeguarding, and maintaining all SQA-related records, and (8) organizational roles and responsibilities relative to product quality.

第355页

Page 355

17.10 总结

17.10 Summary

软件质量保证是软件工程的一项总括活动,应用于软件过程的每个步骤。SQA 包括有效应用方法和工具的程序、质量控制活动的监督(例如技术审查和软件测试)、变更管理程序、确保符合标准的程序以及测量和报告机制。

Software quality assurance is a software engineering umbrella activity that is applied at each step in the software process. SQA encompasses procedures for the effective application of methods and tools, oversight of quality control activities such as technical reviews and software testing, procedures for change management, procedures for assuring compliance to standards, and measurement and reporting mechanisms.

为了正确地进行软件质量保证,应该收集、评估和传播有关软件工程过程的数据。统计SQA有助于提高产品和软件流程本身的质量。软件可靠性模型扩展了测量范围,使收集的缺陷数据能够外推到预计的故障率和可靠性预测中。

To properly conduct software quality assurance, data about the software engineering process should be collected, evaluated, and disseminated. Statistical SQA helps to improve the quality of the product and the software process itself. Software reliability models extend measurements, enabling collected defect data to be extrapolated into projected failure rates and reliability predictions.

总之,您应该注意 Dunn 和 Ullman [Dun82] 的话:“软件质量保证是将质量保证的管理规则和设计规则映射到软件工程的适用管理和技术空间上。” 保证质量的能力是衡量一个工程学科是否成熟的标准。成功完成映射后,就会产生成熟的软件工程。

In summary, you should note the words of Dunn and Ullman [Dun82]: “Software quality assurance is the mapping of the managerial precepts and design disciplines of quality assurance onto the applicable managerial and technological space of software engineering.” The ability to ensure quality is the measure of a mature engineering discipline. When the mapping is successfully accomplished, mature software engineering is the result.

问题与思考点

Problems and Points to Ponder

17.1。有人说“变异控制是质量控制的核心”。因为创建的每个程序都与其他程序不同,所以我们寻找哪些变化以及如何控制它们?

17.1. Some people say that “variation control is the heart of quality control.” Because every program that is created is different from every other program, what are the variations that we look for and how do we control them?

17.2. 如果客户不断改变它应该做的事情,是否可以评估软件的质量?

17.2. Is it possible to assess the quality of software if the customer keeps changing what it is supposed to do?

17.3。质量和可靠性是相关的概念,但在许多方面有根本的不同。讨论差异。

17.3. Quality and reliability are related concepts but are fundamentally different in a number of ways. Discuss the differences.

17.4。一个程序可能是正确的但仍然不可靠吗?解释。

17.4. Can a program be correct and still not be reliable? Explain.

17.5。一个程序是否可能是正确的,但仍然没有表现出良好的质量?解释。

17.5. Can a program be correct and still not exhibit good quality? Explain.

17.6。为什么软件工程团队和独立的软件质量保证团队之间经常存在紧张关系?这健康吗?

17.6. Why is there often tension between a software engineering group and an independent software quality assurance group? Is this healthy?

17.7。您有责任提高整个组织的软件质量。你应该做的第一件事是什么?下一步是什么?

17.7. You have been given the responsibility for improving the quality of software across your organization. What is the first thing that you should do? What’s next?

17.8。除了计算错误和缺陷之外,软件还有其他可计数的特征来暗示质量吗?它们是什么以及可以直接测量吗?

17.8. Besides counting errors and defects, are there other countable characteristics of software that imply quality? What are they and can they be measured directly?

17.9。MTBF 可靠性概念容易受到批评。解释为什么。

17.9. The MTBF concept for reliability is open to criticism. Explain why.

17.10。考虑两个由计算机控制的安全关键系统。每项至少列出三种可能与软件故障直接相关的危险。

17.10. Consider two safety-critical systems that are controlled by computer. List at least three hazards for each that can be directly linked to software failures.

1如果您还没有阅读第 15 章,您现在应该阅读。

1 If you have not read Chapter 15, you should do so now.

2例如,CMMI 定义的流程和实践(第 28 章)。

2 For example, CMMI-defined process and practices (Chapter 28).

3值得注意的是,MTBF 和相关测量基于 CPU 时间,而不是挂钟时间。

3 It is important to note that MTBF and related measures are based on CPU time, not wall clock time.

4尽管出现故障后可能需要进行调试(和相关更正),但在许多情况下,软件在重新启动后无需其他更改即可正常工作。

4 Although debugging (and related corrections) may be required following a failure, in many cases the software will work properly after a restart with no other change.

5条件概率的贝叶斯定理为 P(A|B) = (P(B|A) * P(A)) / P(B)。有关更多详细信息,请参阅 http://www.statisticshowto.com/bayes-theorem-problems/。

5 Bayes’ theorem for conditional probabilities is P(A|B) = (P(B|A) * P(A)) / P(B). For more details, see http://www.statisticshowto.com/bayes-theorem-problems/.

6这种方法类似于第 26 章中描述的风险分析方法。主要区别在于强调技术问题而不是项目相关主题。

6 This approach is similar to the risk analysis methods described in Chapter 26. The primary difference is the emphasis on technology issues rather than project-related topics.

7本节由 Michael Stovsky 撰写,改编自ISO 9000 基础知识,这是一本为Essential Software Engineering 开发的工作手册,是 RS Pressman & Associates, Inc. 开发的视频课程。经许可转载。

7 This section, written by Michael Stovsky, has been adapted from Fundamentals of ISO 9000, a workbook developed for Essential Software Engineering, a video curriculum developed by R. S. Pressman & Associates, Inc. Reprinted with permission.

第356页

Page 356

章节

chapter

18软件安全工程

18 Software Security Engineering

贡献者:Nancy Mead卡内基梅隆大学软件工程学院

Contributed by: Nancy Mead Carnegie Mellon University Software Engineering Institute

停下来看看周围。您在哪里看到软件被部署?当然,它就在您的笔记本电脑、平板电脑和手机中。您的电器(冰箱、洗碗机等)怎么样?你的车怎么样?金融交易——ATM、网上银行、财务软件、税务软件?您的电力供应商?肯定是用软件。您有可穿戴设备吗?一个合适的位?也许您有医疗设备,例如起搏器。底线是:软件就在我们周围、在我们身上,有时甚至在我们体内。每个软件产品都有可能被黑客攻击,有时会造成可怕的后果。这就是我们作为软件工程师需要关注软件安全的原因。

Stop and take a look around. Where do you see software being deployed? Sure, it’s in your laptop, tablet, and cell phone. What about your appliances—refrigerator, dishwasher, and so forth? How about your car? Financial transactions—ATM, online banking, financial software, tax software? Your supplier of electricity? Definitely using software. Do you have any wearable devices on? A fit-bit? Maybe you have medical devices, like a pacemaker. The bottom line is: Software is all around us, on us, and sometimes in us. Every software product has the potential to be hacked, sometimes with dire consequences. This is the reason that we, as software engineers, need to be concerned about software security.

第357页

Page 357

18.1 为什么软件安全工程很重要

18.1 Why Software Security Engineering Is Important

软件安全不仅仅是通过防火墙、强密码和加密来保护操作软件的安全。它还涉及以从一开始就更加安全的方式开发软件。现在的技术可以帮助我们开发比其他方式更安全的软件。

Software security is about more than just securing operational software with firewalls, strong passwords, and encryption. It’s also about developing software in such a way that it is more secure from the outset. Techniques are now available that will help us develop software that is significantly more secure than it would be otherwise.

在本章中,我们将研究一些可以帮助我们实现更好的软件安全性的模型和技术。我们将从查看安全流程模型开始。然后我们将检查特定的流程活动,包括需求工程、误用或滥用案例、安全风险分析、威胁建模、攻击面、安全编码和测量等活动。我们还将考虑安全流程改进模型。最后,我们将总结并为您提供参考列表,以便您可以更深入地研究这些主题。

In this chapter, we’re going to look as some of the models and techniques that can help us achieve better software security. We’ll start by looking at security process models. Then we’ll examine specific process activities, including such activities as requirements engineering, misuse or abuse cases, security risk analysis, threat modeling, attack surface, secure coding, and measurement. We’ll also consider security process improvement models. Finally, we’ll summarize and provide you with a list of references so that you can dive into any of these topics in more depth.

软件安全工程研究是一个非常活跃的领域。在本书中,我们仅提供支持实际实践的方法和工具的概述。有许多专门针对软件安全工程的书籍(例如,[Mea16]、[Shu13] 和 [Hel18])和其他资源,我们将向您介绍其中的一些。

Software security engineering research is a very active area. In this book we’re only providing an overview of methods and tools to support actual practice. There are many books (for example, [Mea16], [Shu13], and [Hel18]) and other resources devoted exclusively to software security engineering, and we will point you to some of them.

18.2 安全生命周期模型

18.2 Security Life-Cycle Models

Microsoft 安全开发生命周期 (SDL) [Mea16] [Mic18] 是行业领先的软件安全流程。自 2004 年以来,SDL 是一项 Microsoft 范围内的倡议和强制性政策,它使 Microsoft 能够将安全和隐私嵌入其软件和文化中。SDL 在开发过程的早期和整个阶段引入了安全性和隐私性,毫无疑问是最广为人知和使用的安全开发生命周期模型。

The Microsoft Security Development Lifecycle (SDL) [Mea16] [Mic18] is an industry-leading software security process. A Microsoft-wide initiative and a mandatory policy since 2004, the SDL enabled Microsoft to embed security and privacy in its software and culture. The SDL introduces security and privacy early and throughout all phases of the development process and is without question the most widely known and used security development life-cycle model.

Microsoft 定义了一系列原则,称为“设计安全”、“默认安全”、“部署安全”和“通信” (SD3+C),以帮助确定需要在哪些方面进行安全工作。这些如下[Mic10]:

Microsoft defined a collection of principles it calls Secure by Design, Secure by Default, Secure in Deployment, and Communications (SD3+C) to help determine where security efforts are needed. These are as follows [Mic10]:

设计安全

Secure by Design

  • 安全架构、设计和结构。开发人员将安全问题视为软件开发基本架构设计的一部分。他们审查可能的安全问题的详细设计,并设计和开发针对所有威胁的缓解措施。

  • Secure architecture, design, and structure. Developers consider security issues part of the basic architectural design of software development. They review detailed designs for possible security issues, and they design and develop mitigations for all threats.

  • 威胁建模和缓解。创建威胁模型,并在所有设计和功能规范中提供威胁缓解措施。

  • Threat modeling and mitigation. Threat models are created, and threat mitigations are present in all design and functional specifications.

  • 消除漏洞。经过审查后,代码中不存在会对软件的预期使用带来重大风险的已知安全漏洞。此审查包括使用分析和测试工具来消除各类漏洞。

  • Elimination of vulnerabilities. No known security vulnerabilities that would present a significant risk to the anticipated use of the software remain in the code after review. This review includes the use of analysis and testing tools to eliminate classes of vulnerabilities.

  • 安全性的改进。不推荐使用安全性较低的遗留协议和代码,并且在可能的情况下,为用户提供符合行业标准的安全替代方案。

  • Improvements in security. Less secure legacy protocols and code are deprecated, and, where possible, users are provided with secure alternatives that are consistent with industry standards.

默认安全

Secure by Default

  • 最小特权。所有组件都以尽可能少的权限运行。

  • Least privilege. All components run with the fewest possible permissions.

  • 纵深防御。组件不依赖于单一的威胁缓解解决方案,如果该解决方案失败,就会使用户面临风险。

  • Defense in depth. Components do not rely on a single threat mitigation solution that leaves users exposed if it fails.

  • 第358页保守的默认设置。开发团队了解产品的攻击面,并在默认配置中将其最小化。

  • Page 358Conservative default settings. The development team is aware of the attack surface for the product and minimizes it in the default configuration.

  • 避免有风险的默认变更。应用程序不会对操作系统或安全设置进行任何会降低主机安全性的默认更改。在某些情况下,例如对于安全产品,软件程序加强(增加)主机的安全设置是可以接受的。最常见的违反此原则的行为是游戏在未通知用户的情况下打开防火墙端口,或在未告知用户可能存在的风险的情况下指示用户打开防火墙端口。

  • Avoidance of risky default changes. Applications do not make any default changes to the operating system or security settings that reduce security for the host computer. In some cases, such as for security products, it is acceptable for a software program to strengthen (increase) security settings for the host computer. The most common violations of this principle are games that either open firewall ports without informing the user or instruct users to open firewall ports without informing users of possible risks.

  • 不太常用的服务默认关闭。如果少于 80% 的程序用户使用某项功能,则默认情况下不应激活该功能。衡量产品 80% 的使用率通常很困难,因为程序是针对许多不同的角色设计的。考虑某个功能是否满足所有角色的核心/主要使用场景可能很有用。如果是,则该功能有时称为 P1 功能。

  • Less commonly used services off by default. If fewer than 80 percent of a program’s users use a feature, that feature should not be activated by default. Measuring 80 percent usage in a product is often difficult because programs are designed for many different personas. It can be useful to consider whether a feature addresses a core/primary use scenario for all personas. If it does, the feature is sometimes referred to as a P1 feature.

安全部署

Secure in Deployment

  • 部署指南。规范性部署指南概述了如何安全地部署程序的每个功能,包括为用户提供信息,使他们能够评估激活非默认选项的安全风险(从而增加攻击面)。

  • Deployment guides. Prescriptive deployment guides outline how to deploy each feature of a program securely, including providing users with information that enables them to assess the security risk of activating non-default options (and thereby increasing the attack surface).

  • 分析和管理工具。安全分析和管理工具使管理员能够确定和配置软件版本的最佳安全级别。

  • Analysis and management tools. Security analysis and management tools enable administrators to determine and configure the optimal security level for a software release.

  • 补丁部署工具。部署工具有助于补丁部署。

  • Patch deployment tools. Deployment tools aid in patch deployment.

通讯

Communications

  • 安全响应。开发团队及时响应安全漏洞报告并传达有关安全更新的信息。

  • Security response. Development teams respond promptly to reports of security vulnerabilities and communicate information about security updates.

  • 社区参与。开发团队主动与用户互动,回答有关安全漏洞、安全更新或安全环境变化的问题。

  • Community engagement. Development teams proactively engage with users to answer questions about security vulnerabilities, security updates, or changes in the security landscape.

安全软件开发过程模型如图18.1所示。

The secure software development process model looks like the one shown in Figure 18.1.

图18.1 Microsoft 的安全软件开发流程模型

Figure 18.1 Secure Software Development Process Model at Microsoft

改编自 Shunn, A. 等人。《安全解决方案的优势》,卡内基梅隆大学软件工程学院,2013 年。可访问 http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=77878。

Adapted from Shunn, A., et al. Strengths in Security Solutions, Software Engineering Institute, Carnegie Mellon University, 2013. Available at http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=77878.

Microsoft SDL 文档描述了架构师、设计人员、开发人员和测试人员需要为 16 种推荐实践中的每一种执行哪些操作。Microsoft 在实施 SDL 后收集的数据显示,漏洞显着减少,从而减少了补丁的需求,从而显着节省了成本。我们建议您浏览 SDL 网站以了解有关这些实践的更多信息。自 SDL 开发以来,已有大量论文、书籍、培训等与 SDL 模型相配合。1

The Microsoft SDL documentation describes what architects, designers, developers, and testers are required to do for each of the 16 recommended practices. The data that Microsoft collected after implementing the SDL shows a significant reduction in vulnerabilities, which led to a need for fewer patches, and thus a significant cost savings. We recommend that you browse the SDL website to learn more about these practices. Since the SDL was developed, there have been numerous papers, books, training, and so on, to go with the SDL model.1

第359页

Page 359

18.3 安全开发生命周期活动

18.3 Secure Development Life-Cycle Activities

独立于生命周期模型的另一种方法是软件安全接触点 [McG06],它认为活动接触点)才是重要的,而不是模型。这些活动可以合并到任何生命周期模型中,因此被认为是与流程无关的。这些接触点后来形成了 BSIMM 的基础,这是本章稍后讨论的成熟度模型。一些组织认为接触点是安全软件开发中应执行的最小活动集。接触点的图示版本如图 18.2所示。在此图中,建议的安全活动显示在相应的软件开发活动或生命周期阶段之上:

A different approach that is independent of a life-cycle model is the touchpoints for software security [McG06], which argues that the activities (touchpoints) are what matter, not the model. The activities can be incorporated into any life-cycle model, and thus are considered to be process agnostic. The touchpoints later formed the basis for BSIMM, a maturity model that will be discussed later in this chapter. Some organizations consider the touchpoints to be the minimum set of activities that should be performed in secure software development. A pictorial version of the touchpoints is shown in Figure 18.2. In this diagram, the recommended security activities appear above the corresponding software development activity, or life-cycle phase:

图18.2 软件安全接触

Figure 18.2 Software security touchpoints

考虑到 SDL 和接触点,我们将了解一些与其相关的重要安全软件开发活动。

With the SDL and touchpoints in mind, we’ll look at some of the important secure software development activities that are associated with them.

第360页

Page 360

18.4 安全需求工程

18.4 Security Requirements Engineering

尽管安全需求是安全软件开发的重要组成部分,但在实践中它们常常被忽视。当它们存在时,它们通常是一个附加组件,是从安全功能的通用列表中复制的。获得一组更好的安全需求所需的需求工程很少发生[All08]。

Although security requirements are an important part of secure software development, in practice they are often neglected. When they exist, they are often an add-on, copied from a generic list of security features. The requirements engineering that is needed to get a better set of security requirements seldom takes place [All08].

需求工程实践通常解决所需的用户功能。因此,从用户的角度关注系统的功能,但很少关注系统不应该做什么[ Bis02]。用户期望系统是安全的,并且这些假设需要在软件系统开发之前而不是在开发之后纳入软件系统的安全要求中。用户关于安全性的假设常常被忽视,因为系统功能是主要关注点。

Requirements engineering practice typically addresses desired user features. Therefore, attention is given to the functionality of the system from the user’s perspective, but little attention is given to what the system should not do [Bis02]. Users expect systems to be secure, and these assumptions need to make their way into security requirements for software systems before they are developed, not after the fact. Often the users’ assumptions about security are overlooked because system features are the primary focus.

除了安全生命周期模型之外,还有许多特定于安全需求的流程模型。其中包括:核心安全需求工件 [Mof04]、软件成本降低 (SCR) [Hei02]、SQUARE(安全质量需求工程)[Mea05] 和安全需求工程流程 (SREP) [Mel06]。在本节的其余部分中,我们将把 SQUARE 视为安全生命周期模型的代表性示例。

In addition to security life-cycle models, there are many process models that are specific to security requirements. These include: core security requirements artifacts [Mof04], Software Cost Reduction (SCR) [Hei02], SQUARE (Security QUAlity Requirements Engineering) [Mea05], and Security Requirements Engineering Process (SREP) [Mel06]. For the remainder of this section, we’ll consider SQUARE as a representative example of security life-cycle models.

18.4.1 正方形

18.4.1 SQUARE

SQUARE 是一种具有代表性的安全需求工程过程模型,但请务必记住,如果您已经有了一个开发过程模型(例如第 4 章中介绍的模型),您只需采取一些 SQUARE 步骤来增强现有的模型。无需开发全新的流程来解决软件开发活动中的安全问题。我们建议您将安全定义添加到术语表中;执行风险分析,包括通过误用案例或威胁建模识别潜在攻击;制定缓解策略;并对候选人的安全要求进行分类和优先级排序。

SQUARE is a representative security requirements engineering process model, but it’s important to keep in mind that if you already have a development process model, such as the one presented in Chapter 4, you can just pick up some of the SQUARE steps to enhance your existing model. There’s no need to develop a whole new process to address security in your software development activities. We suggest that you add security definitions to your glossary; perform risk analysis, including identification of potential attacks via misuse cases or threat modeling; develop mitigation strategies; and perform categorization and prioritization of candidate security requirements.

SQUARE 过程模型可以对软件密集型系统的安全需求进行引出、分类和优先级排序。其重点是将安全概念构建到开发生命周期的早期阶段。它还可用于现场系统以及正在进行改进和修改的系统。该过程如表 18.1所示,后面是每个步骤的简要描述。

The SQUARE process model provides for eliciting, categorizing, and prioritizing security requirements for software-intensive systems. Its focus is to build security concepts into the early stages of the development life cycle. It can also be used for fielded systems and those undergoing improvements and modifications. The process is shown in Table 18.1, followed by brief descriptions of each step.

18.4.2 平方过程

18.4.2 The SQUARE Process

SQUARE 流程最好由项目的需求工程师和安全专家以及执行管理层和利益相关者的支持来应用。我们来看看步骤吧。2

The SQUARE process is best applied by the project’s requirements engineers and security experts with supportive executive management and stakeholders. Let’s take a look at the steps.2

  • 步骤 1. 就定义达成一致。为了不出现语义混淆,此步骤是安全需求工程的先决条件。在给定的项目中,团队成员往往会根据他们之前的经验记住定义,但这些定义通常彼此不同 [Woo05]。电气和电子工程师协会 (IEEE) 和软件工程知识体系 (SWEBOK) 等来源提供了一系列定义供选择或定制 [SWE14]。

  • Step 1. Agree on definitions. So that there is not semantic confusion, this step is needed as a prerequisite to security requirements engineering. On a given project, team members tend to have definitions in mind, based on their prior experience, but those definitions are often different from one another [Woo05]. Sources such as the Institute for Electrical and Electronics Engineers (IEEE) and the Software Engineering Body of Knowledge (SWEBOK) provide a range of definitions to select from or tailor [SWE14].

  • 第362页步骤 2. 确定资产和安全目标。此步骤发生在项目的组织级别,并且需要支持软件开发。不同的利益相关者通常关注不同的资产,因此有不同的目标。例如,人力资源领域的利益相关者可能关心维护人事记录的机密性,而研究领域的利益相关者可能关心确保研究项目信息不被访问、修改或窃取。

  • Page 362Step 2. Identify assets and security goals. This step occurs at the project’s organizational level and is needed to support software development. Different stakeholders usually have concerns about different assets, and thus have different goals. For example, a stakeholder in human resources may be concerned about maintaining the confidentiality of personnel records, whereas a stakeholder in a research area may be concerned with ensuring that research project information is not accessed, modified, or stolen.

  • 步骤 3. 开发工件。此步骤对于支持所有后续安全需求工程活动是必要的。通常,组织没有支持需求定义所需的关键文档,或者它们可能不是最新的。这意味着可能会花费大量时间回溯以尝试获取文档,或者团队必须在进一步操作之前更新它们。

  • Step 3. Develop artifacts. This step is necessary to support all subsequent security requirements engineering activities. Often, organizations do not have key documents needed to support requirements definition, or they may not be up to date. This means that a lot of time may be spent backtracking to try to obtain documents, or the team will have to bring them up to date before going further.

  • 步骤 4. 进行风险评估。此步骤需要风险评估方法方面的专家、利益相关者的支持以及安全需求工程师的支持。风险评估方法有很多种,但无论您选择哪一种,风险评估的结果都可以帮助识别高优先级的安全风险。

  • Step 4. Perform risk assessment. This step requires an expert in risk assessment methods, the support of the stakeholders, and the support of a security requirements engineer. There are a number of risk assessment methods, but regardless of the one that you choose, the outcomes of risk assessment can help in identifying the high-priority security exposures.

  • 步骤 5. 选择启发技术。当利益相关者不同时,这一步骤就变得很重要。当利益相关者具有不同文化背景时,更正式的启发技术,例如加速需求方法 [Hub99]、联合应用程序设计 [Woo89] 或结构化访谈,可以有效克服沟通问题。在其他情况下,启发可能只是与主要利益相关者坐下来尝试了解该利益相关者的安全需求。

  • Step 5. Select elicitation technique. This step becomes important when there are diverse stakeholders. A more formal elicitation technique, such as the Accelerated Requirements Method [Hub99], Joint Application Design [Woo89], or structured interviews, can be effective in overcoming communication issues when there are stakeholders with different cultural backgrounds. In other cases, elicitation may simply consist of sitting down with a primary stakeholder to try to understand that stakeholder’s security requirements needs.

  • 步骤 6. 得出安全要求。此步骤涵盖使用所选技术的实际启发过程。大多数启发技术都提供有关如何执行启发的详细指导。这建立在早期步骤中开发的工件的基础上。

  • Step 6. Elicit security requirements. This step encompasses the actual elicitation process using the selected technique. Most elicitation techniques provide detailed guidance on how to perform elicitation. This builds on the artifacts that were developed in earlier steps.

  • 步骤 7. 对需求进行分类。此步骤允许安全需求工程师区分基本需求、目标(期望的需求)和可能存在的架构约束。这种分类也有助于随后的优先级划分活动。

  • Step 7. Categorize requirements. This step allows the security requirements engineer to distinguish among essential requirements, goals (desired requirements), and architectural constraints that may be present. This categorization also helps in the prioritization activity that follows.

  • 步骤 8. 确定需求的优先级。此步骤取决于前一步骤,并且还可能涉及执行成本效益分析,以确定哪些安全需求相对于其成本具有较高的回报。当然,优先级也可能取决于安全漏洞的其他后果,例如生命损失、声誉损失和消费者信心丧失。第363页

  • Step 8. Prioritize requirements. This step depends on the prior step and may also involve performing a cost-benefit analysis to determine which security requirements have a high payoff relative to their cost. Of course prioritization may also depend on other consequences of security breaches, such as loss of life, loss of reputation, and loss of consumer confidence.Page 363

  • 步骤9.需求检查。这种审查活动可以以不同的正式程度来完成,这将在第 16 章中讨论。检查完成后,项目团队应该有一组初始的优先安全要求,可以在项目后期根据需要重新访问。

  • Step 9. Requirements inspection. This review activity can be accomplished at varying levels of formality, discussed in Chapter 16. Once inspection is complete, the project team should have an initial set of prioritized security requirements that can be revisited as needed later in the project.

18.5 误用和滥用案例以及攻击模式

18.5 Misuse and Abuse Cases and Attack Patterns

误用(或滥用)案例可以帮助您以与攻击者相同的方式查看您的软件。通过思考负面事件,您可以更好地了解如何开发安全软件。误用案例可以被视为攻击者发起的用例。

Misuse (or abuse) cases can help you view your software in the same way that attackers do. By thinking about negative events, you can better understand how to develop secure software. A misuse case can be thought of as a use case that the attacker initiates.

误用案例 [Sin00] 的目标之一是预先决定软件应如何应对潜在的攻击。您还可以结合使用误用和正常用例来进行威胁和危害分析 [Ale03]。

One of the goals of misuse cases [Sin00] is to decide up front how software should react to potential attacks. You can also use misuse and normal use cases together to conduct threat and hazard analysis [Ale03].

我们建议通过头脑风暴来创建误用案例。安全专家与主题专家 (SME) 的合作可以快速覆盖很多领域。在头脑风暴过程中,软件安全专家会向开发人员提出许多问题,以帮助识别系统可能存在弱点的地方。这需要仔细查看所有用户界面,并考虑开发人员认为不会发生但攻击者实际上可能导致发生的事件。

We suggest creating misuse cases through brainstorming. Teaming security experts with subject matter experts (SMEs) covers a lot of ground quickly. During brainstorming, software security experts ask many questions of developers to help identify the places where the system is likely to have weaknesses. This involves a careful look at all user interfaces and considers events that developers assume can’t happen, but that attackers can actually cause to happen.

这里有一些需要考虑的问题:系统如何区分输入数据的有效和无效?它能否判断请求是来自合法应用程序还是恶意应用程序?内部人员会导致系统故障吗?尝试回答这些问题可以帮助开发人员分析他们的假设,并允许他们提前解决问题。

Here are some questions that need to be considered: How can the system distinguish between valid and invalid input data? Can it tell whether a request is coming from a legitimate application or a rogue application? Can an insider cause a system to malfunction? Trying to answer such questions helps developers to analyze their assumptions and allows them to fix problems up front.

误用案例可以采用表格或图表的形式。图 18.3提供了一个误用案例示例,展示了 DroidCleaner 恶意软件如何使用名为 K-9 的开源电子邮件应用程序成功攻击手机。这是从您可能希望研究的一份更大的报告中提取的 [Ali14]。

Misuse cases can be in table or diagram form. Figure 18.3 provides an example misuse case that shows how DroidCleaner malware can successfully attack a cell phone using an open-source e-mail application called K-9. This is extracted from a much larger report that you may wish to study [Ali14].

图18.3 误用案例(被DroidCleaner利用):智能手机上存储的电子邮件中的数据被盗

Figure 18.3 Misuse case (exploited by DroidCleaner): Data in an e-mail stored on the smartphone is stolen

在这种误用情况下,用户将电子邮件保存在手机的外部存储区域中。攻击者通过破坏操作系统来访问手机的存储空间。攻击者获取手机访问权限的常见方法是诱骗用户安装特洛伊木马,用户在安装过程中无意中授予对驱动器的访问权限。然后,攻击者就可以使用该特洛伊木马下载文件,包括电子邮件内容文件。

In this misuse case, the user keeps e-mail on the phone’s external storage area. The attacker gains access to the phone’s storage by compromising the operating system. A common way for the attacker to gain access to the phone is by tricking the user into installing a Trojan, to which the user unwittingly grants access to the drive during the install process. The attacker is then able to use the Trojan to download files, including the e-mail contents file.

攻击模式可以通过提供创建攻击的蓝图来提供一些帮助。例如,缓冲区溢出是一种安全漏洞利用。试图利用缓冲区溢出的攻击者会使用类似的步骤 [OWA16]。攻击模式可以记录这些步骤(例如,时间、资源、技术)以及软件开发人员可以用来防止或减轻其成功的实践[Hog04]。当您尝试开发误用和滥用案例时,攻击模式可以提供帮助。

Attack patterns can provide some help by providing a blueprint for creating an attack. For example, buffer overflow is one type of security exploitation. Attackers trying to capitalize on a buffer overflow make use of similar steps [OWA16]. Attack patterns can document these steps (e.g., timing, resources, techniques) as well as practices software developers can use to prevent or mitigate their success [Hog04]. When you’re trying to develop misuse and abuse cases, attack patterns can help.

误用案例在产生时需要优先考虑。此外,他们需要在成本和收益之间取得适当的平衡。项目预算可能不允许软件团队立即实施所有定义的缓解策略。在这种情况下,可以优先考虑策略并逐步实施。该团队还可以排除某些极不可能发生的情况。第364页

Misuse cases need to be prioritized as they are generated. In addition, they need to strike the right balance between cost and benefit. The project budget may not allow a software team to implement all defined mitigation strategies at once. In such cases, the strategies can be prioritized and implemented incrementally. The team can also exclude certain cases as being extremely unlikely.Page 364

误用和滥用案例的模板出现在许多参考文献中。它们可以是文本或图表,并且可以得到工具的支持。Sindre 和 Opdahl [Sin01] 以及 Alexander [Ale02] 提供的材料是很好的模板来源。

Templates for misuse and abuse cases appear in a number of references. They can be text or diagrams and may be supported by tools. Good sources for templates are in materials by Sindre and Opdahl [Sin01] and Alexander [Ale02].

18.6 安全风险分析

18.6 Security Risk Analysis

已经提出了多种安全风险评估方法。典型示例包括 SEI CERT 的安全工程风险分析 (SERA) 方法3和 NIST 风险管理框架 (RMF)。4

A wide variety of security risk assessment methods have been proposed. Typical examples include SEI CERT’s Security Engineering Risk Analysis (SERA) method3 and the NIST Risk Management Framework (RMF).4

RMF 已成为一种广泛使用的方法,为用户提供指导。RMF 的安全步骤是:

RMF has emerged as an approach that is widely used, providing guidelines for the users. The RMF steps for security are:

  • 根据影响分析对信息系统以及该系统处理、存储和传输的信息进行分类。

  • Categorize the information system and the information processed, stored, and transmitted by that system based on an impact analysis.

  • 根据安全分类,为信息系统选择一套初始的基线安全控制;使用对风险和当地条件的组织评估,根据需要定制和补充安全控制基线。

  • Select an initial set of baseline security controls for the information system based on the security categorization; using an organizational assessment of risk and local conditions, tailor and supplement the security control baseline as needed.

  • 实施安全控制,并描述如何在信息系统及其操作环境中使用这些控制。

  • Implement the security controls, and describe how the controls are employed within the information system and its operational environment.

  • 使用适当的评估程序来评估安全控制,以确定控制正确实施、按预期运行以及产生满足系统安全要求的预期结果的程度。第365页

  • Assess the security controls using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.Page 365

  • 根据对组织运营和资产、个人或其他组织(包括国防)的风险的确定,对信息系统的操作进行授权,从信息系统的操作来看,该风险是可以接受的

  • Authorize the information system operation based on a determination of the risk to organizational operations and assets, individuals, or other organizations (including national defense), from the operation of the information system that this risk is acceptable.

  • 持续监控信息系统中的安全控制,包括评估控制有效性、记录系统或其运行环境的变更、对相关变更进行安全影响分析以及向指定的组织官员报告系统的安全状态

  • Monitor the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.

值得注意的是,NIST 还提供了一组安全控制措施可供选择,从而简化了风险评估工作。最近,RMF 进行了修改,纳入了隐私问题。

It’s important to note that NIST also provides a set of security controls to select from, thus simplifying the risk assessment work. Recently, the RMF has been modified to include privacy concerns.

18.7 威胁建模、优先级划分和缓解

18.7 Threat Modeling, Prioritization, and Mitigation

威胁建模方法(TMM)是一种创建软件系统抽象的方法,旨在识别攻击者的能力和目标,并使用该抽象来生成和分类系统必须缓解的可能威胁[Shu16]。

A threat modeling method (TMM) is an approach for creating an abstraction of a software system, aimed at identifying attackers’ abilities and goals, and using that abstraction to generate and catalog possible threats that the system must mitigate [Shu16].

STRIDE(六个威胁类别的缩写)代表了多种威胁建模方法 [Mea18],并且是最成熟的 TMM,代表了实践的状态。从本质上讲,STRIDE 需要将系统分解为各个元素,评估每个元素对威胁的脆弱性,然后减轻这些威胁 [Her06]。在实践中,典型的 STRIDE 实施包括使用数据流图 (DFD) 对系统进行建模,5将 DFD 元素映射到六个威胁类别,通过检查表或威胁树确定特定威胁,并记录威胁及其预防步骤。斯卡15]。STRIDE可以手动实现;但是,也可以使用免费的 Microsoft 安全开发生命周期 (SDL) 威胁建模工具 [Mic17]。表 18.2标识了与六个威胁类别中的每一个相关的安全属性。

STRIDE (an acronym for six threat categories) is representative of a number of threat modeling methods [Mea18] and is the most well-established TMM, representing the state of the practice. At its core, STRIDE requires breaking down a system into its various elements, assessing each of these elements for their vulnerability to threats, and then mitigating these threats [Her06]. In practice, a typical STRIDE implementation includes modeling a system with data flow diagrams (DFDs),5 mapping the DFD elements to the six threat categories, determining the specific threats via checklists or threat trees, and documenting the threats and steps for their prevention [Sca15]. STRIDE can be implemented manually; however, a free Microsoft Secure Development Lifecycle (SDL) Threat Modeling Tool [Mic17] can also be used. Table 18.2 identifies the security property associated with each of the six threat categories.

第366页DFD 旨在通过使用标准符号以图形方式表示数据存储(例如数据库、文件、注册表)、进程(例如 DLL、Web 服务)、数据流(例如函数调用、远程过程调用)和外部实体(例如,人、其他系统)[Sho14]。一旦完成,这些系统元素中的每一个都可以与一个或多个相关威胁类别相关联,如表 18.3所示。

Page 366DFDs are designed to show how a system works by using standard symbols to graphically represent the interaction between data stores (e.g., databases, files, registries), processes (e.g., DLLs, Web services), data flows (e.g., function calls, remote procedure calls), and external entities (e.g., people, other systems) [Sho14]. Once complete, each of these system elements in turn can be associated with one or more relevant threat categories, as depicted in Table 18.3.

在下一阶段,典型的 STRIDE 用户通过与 DFD 元素和威胁类别之间的每个匹配相关联的特定威胁的清单(可能采用威胁树的形式)进行工作。此类清单可通过 STRIDE 参考书或工具获取。

In the next stage, the typical STRIDE user works through a checklist (that may be in the form of a threat tree) of specific threats that are associated with each match between a DFD element and threat category. Such checklists are accessible through STRIDE reference books or tools.

一旦识别出威胁,就可以制定缓解策略并确定优先级。通常,优先级是基于成本和价值考​​虑的。考虑实施缓解策略的成本很重要,但同样重要的是还要考虑不实施该策略的成本,这反映在价值中。请记住,已实现的风险会导致成本,这些成本不仅以美元表示,还可能反映出声誉损失、信任损失,甚至生命损失。

Once the threats have been identified, mitigation strategies can be developed and prioritized. Typically, prioritization is based on cost and value considerations. Considering the cost of implementing the mitigation strategy is important, but it’s equally important to also consider the cost of not implementing it, which is reflected in value. Remember that risks that are realized result in costs that are not only expressed in terms of dollars, but could also reflect loss of reputation, loss of trust, and even loss of life.

18.8 攻击面

18.8 Attack Surface

攻击可以通过以下方式定义6 :

An attack surface can be defined6 in the following manner:

攻击面描述了攻击者可以进入系统以及可以从何处获取数据的所有不同点。

The attack surface describes all of the different points where an attacker could get into a system, and where they could get data out.

应用程序的攻击面是:

The attack surface of an application is:

  1. 数据/命令进出应用程序的所有路径的总和,以及

  2. the sum of all paths for data/commands into and out of the application, and

  3. 保护这些路径的代码(包括资源连接和身份验证、授权、活动日志记录、数据验证和编码),以及

  4. the code that protects these paths (including resource connection and authentication, authorization, activity logging, data validation and encoding), and

  5. 应用程序中使用的所有有价值的数据,包括秘密和密钥、知识产权、关键业务数据、个人数据和 PII,以及

  6. all valuable data used in the application, including secrets and keys, intellectual property, critical business data, personal data and PII, and

  7. 保护这些数据的代码(包括加密和校验和、访问审核以及数据完整性和操作安全控制)。[OWA18]

  8. the code that protects these data (including encryption and checksums, access auditing, and data integrity and operational security controls). [OWA18]

第367页OWASP 基金会 [OWA18] 指出攻击面分析是:

Page 367The OWASP Foundation [OWA18] states that attack surface analysis is:

。。。旨在供开发人员在设计和更改应用程序时用于了解和管理应用程序安全风险,以及供应用程序安全专家进行安全风险评估。这里的重点是保护应用程序免受外部攻击 - 它没有考虑对系统用户或操作员的攻击(例如,恶意软件注入、社会工程攻击),并且较少关注内部威胁,尽管原则保持不变。内部攻击面可能与外部攻击面不同,并且某些用户可能拥有大量访问权限。

. . . targeted to be used by developers to understand and manage application security risks as they design and change an application, as well as by application security specialists doing a security risk assessment. The focus here is on protecting an application from external attack—it does not take into account attacks on the users or operators of the system (e.g., malware injection, social engineering attacks), and there is less focus on insider threats, although the principles remain the same. The internal attack surface is likely to be different to the external attack surface and some users may have a lot of access.

攻击面分析是为了确定系统的哪些部分需要检查和测试安全漏洞。攻击面分析的目的是了解应用程序中的风险区域,使开发人员和安全专家了解应用程序的哪些部分容易受到攻击,找到最小化攻击面的方法,并注意攻击面何时以及如何发生变化以及从风险角度来看这意味着什么。

Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of attack surface analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective.

18.9 安全编码

18.9 Secure Coding

安全编码正如其名称所暗示的那样——以不会因编码错误而引入漏洞的方式进行编码。毫不奇怪,大多数软件漏洞的发生都是由于草率和错误的编码实践,其中许多漏洞是可以轻松避免的。

Secure coding is just what the name implies—coding in such a way that vulnerabilities are not introduced as a result of coding errors. It’s not surprising that most software vulnerabilities occur because of sloppy and erroneous coding practices, many of which can be easily avoided.

例如,称为缓冲区溢出的情况是由最知名和最常见的编码错误之一引起的。OWASP 7对此的描述如下:

For example, a condition known as buffer overflow results from one of the most well-known and common coding errors. OWASP7 describes it as follows:

当程序试图将比缓冲区所能容纳的更多的数据放入缓冲区时,或者当程序试图将数据放入超过缓冲区的存储区域时,就会出现缓冲区溢出情况。在这种情况下,缓冲区是分配的连续内存部分,用于包含从字符串到整数数组的任何内容。在分配的内存块的范围之外进行写入可能会损坏数据、使程序崩溃或导致恶意代码的执行。

A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code.

缓冲区溢出只是可能导致漏洞的编码错误的示例之一。幸运的是,现在存在许多编码标准来提供安全编码的指导。SEI/CERT 网站8提供了十大安全编码实践的列表:

Buffer overflow is just one example of coding errors that can result in vulnerabilities. Fortunately, a number of coding standards now exist to provide guidance on secure coding. The SEI/CERT website8 provides a list of the top-10 secure coding practices:

  1. 验证输入。验证来自所有不受信任的数据源的输入。

  2. Validate input. Validate input from all untrusted data sources.

  3. 注意编译器警告。使用编译器可用的最高警告级别来编译代码,并通过修改代码消除警告。

  4. Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code.

  5. 安全策略的架构师和设计。创建软件架构并设计软件以实施和执行安全策略。

  6. Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies.

  7. 把事情简单化。保持设计尽可能简单和尽可能小。

  8. Keep it simple. Keep the design as simple and as small as possible.

  9. 默认拒绝。访问决策基于许可而不是排除。第368页

  10. Default deny. Base access decisions on permission rather than exclusion.Page 368

  11. 坚持最小特权原则。每个进程都应该以完成作业所需的最少权限来执行。

  12. Adhere to the principle of least privilege. Every process should execute with the least set of privileges necessary to complete the job.

  13. 清理发送到其他系统的数据。清理传递到复杂子系统(例如命令 shell、关系数据库和商业现成 (COTS) 组件)的所有数据。

  14. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems such as command shells, relational databases, and commercial off-the-shelf (COTS) components.

  15. 练习纵深防守。通过多种防御策略管理风险。

  16. Practice defense in depth. Manage risk with multiple defensive strategies.

  17. 使用有效的质量保证技术。

  18. Use effective quality assurance techniques.

  19. 采用安全编码标准。

  20. Adopt a secure coding standard.

SEI CERT 和其他机构也提供安全编码标准。9除了使用安全编码标准之外,您还应该检查导致漏洞的编码错误。这只是正常代码检查和审查过程(第 16 章)的自然附加内容。静态分析工具10用于自动分析代码并且是用于检测由于编码错误而导致的漏洞的另一种机制。

SEI CERT and others also provide secure coding standards.9 In addition to using a secure coding standard, you should inspect for coding errors that lead to vulnerabilities. This is just a natural add-on to your normal code inspection and review process (Chapter 16). Static analysis tools10 are used to automatically analyze code and are another mechanism for detecting vulnerabilities due to coding errors.

18.10 测量

18.10 Measurement

制定适当的软件安全措施是一个难题,对此存在不同的观点。一方面,您可以查看所遵循的开发流程并评估最终的软件是否可能安全。另一方面,您可以查看漏洞和成功入侵的发生率,并对其进行衡量,作为评估软件安全性的一种方式。然而,这两种测量方法都无法让您 100% 确定我们的软件是安全的。当添加操作系统和外部可互操作系统等支持软件时,软件安全性的衡量变得更加困难。尽管如此,还是取得了一些进展。

Developing adequate measures of software security is a difficult problem, and one for which there are differing viewpoints. On the one hand, you can look at the development processes followed and assess whether the resultant software is likely to be secure. On the other hand, you can look at the incidence of vulnerabilities and successful break-ins and measure those as a way of assessing software security. However, neither of these measurement approaches will allow you to say with 100 percent certainty that our software is secure. When you add supporting software such as operating systems and external interoperable systems, the measurement of software security becomes even more difficult. Nevertheless some progress has been made.

软件质量的衡量对于衡量软件安全性有很大帮助。具体来说,漏洞总是指向软件缺陷。尽管并非所有软件缺陷都是安全问题,但软件中的漏洞通常是由某种缺陷引起的,无论是需求、架构还是代码。因此,缺陷和漏洞计数等措施 [Woo14] 是有用的。Microsoft 使用攻击面分析等措施,并尝试将攻击面(软件可能受到损害的地方)保持在最低限度。

Measures of software quality can go a long way toward measuring software security. Specifically, vulnerabilities invariably point to software defects. Although not all software defects are security problems, vulnerabilities in software generally result from a defect of some kind, whether it is in the requirements, architecture, or code. Therefore, measures such as defect and vulnerability counts [Woo14] are useful. Microsoft uses measures such as attack surface analysis and tries to keep the attack surface (places where software can be compromised) to a minimum.

正如使用 CMMI(第 28 章)等成熟度模型表明将产生更高质量的软件一样,成熟的安全开发流程(如 BSIMM 11所强调的流程)也将产生更安全的软件。在某些情况下,鼓励组织确定与其相关的一组独特的安全指标。BSIMM 和 SAMM 都参考了这一点。12

Just as use of maturity models such as CMMI (Chapter 28) suggests that higher-quality software will result, mature security development processes, such as those emphasized by BSIMM,11 will result in more secure software. In some cases, organizations are encouraged to identify the unique set of security metrics that are relevant to them. BSIMM makes reference to this, as does SAMM.12

第369页值得注意的是,各种成熟度模型所暗示的测量特征都不是完美的。如果您遵循良好的安全软件开发流程,是否可以保证软件的安全?不!如果您发现很多漏洞,这是否意味着大多数漏洞已经被发现,或者还有更多漏洞有待发现,因为这是一个特别糟糕的软件?没有简单的答案。然而,为了评估漏洞和相关的软件安全性,我们必须收集数据,以便可以随着时间的推移分析模式。如果我们不收集有关软件安全的数据,我们将永远无法衡量其改进情况。

Page 369It’s important to note that none of the measurement characteristics implied by various maturity models is perfect. If you follow good secure software development processes, does that guarantee that the software is secure? No! If you find a lot of vulnerabilities, does that mean that most of them have been found or that there are still more to be found because this is a particularly poor piece of software? There are no simple answers. However, to assess vulnerabilities and associated software security, we have to collect data so that patterns can be analyzed over time. If we don’t collect data about software security, we will never be able to measure its improvement.

表 18.418.5提供了如何在每个生命周期阶段评估软件安全性的示例。完整的表格和讨论可以在 [Mea17] 和 [Alb10] 中找到。

Tables 18.4 and 18.5 provide examples of how to assess software security during each life-cycle phase. The full tables and discussion can be found in [Mea17] and [Alb10].

第370页

Page 370

18.11 安全流程改进和成熟度模型

18.11 Security Process Improvement and Maturity Models

一般而言,许多流程改进和成熟度模型可用于软件开发,例如能力成熟度模型集成(CMMI)。13对于网络安全成熟度,CMMI 研究所提供了一种更新产品,即网络能力成熟度管理平台。14 OWASP 提供软件保障成熟度模型 (SAMM)。15 SAMM 是一个开放框架,可帮助组织制定和实施针对组织面临的特定风险量身定制的软件安全策略。

A number of process improvement and maturity models are available for software development in general, such as the Capability Maturity Model Integration (CMMI).13 For cyber security maturity, the CMMI Institute offers a newer product, the Cyber Capability Maturity Management platform.14 OWASP offers the Software Assurance Maturity Model (SAMM).15 SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization.

对这些模型的全面讨论超出了本书的范围。为了提供简单的概述,请考虑 SAMM 的总体目标:

A comprehensive discussion of these models is beyond the scope of this book. To provide a simple overview, consider the overall objective of SAMM:

  • 评估组织现有的软件安全实践。

  • Evaluate an organization’s existing software security practices.

  • 在明确定义的迭代中构建平衡的软件安全保证计划。

  • Build a balanced software security assurance program in well-defined iterations.

  • 展示对安全保证计划的具体改进。

  • Demonstrate concrete improvements to a security assurance program.

  • 定义并衡量整个组织中与安全相关的活动。

  • Define and measure security-related activities throughout an organization.

也许最著名的专门针对软件安全的成熟度模型是构建安全成熟度模型 (BSIMM)。BSIMM 会定期发布,通常每年或每两年发布一次。BSIMM模型及其最近总结的评估结果可以从BSIMM网站下载。16据 BSIMM 开发人员称,BSIMM 旨在供创建和执行软件安全计划的人员使用。

Perhaps the most well-known maturity model that is specifically for software security is the Building Security in Maturity Model (BSIMM). BSIMM has periodic releases, typically every year or two. The BSIMM model and its recent summarized assessment results can be downloaded from the BSIMM website.16 According to the BSIMM developers, BSIMM is meant to be used by those who create and execute a software security initiative.

这里提到的所有成熟度模型(以及其他模型)都有好处,并且模型的基本元素都是免费提供的。然而,有时评估是由外部实体完成的。可以进行内部自我评估并定义相关的改进计划,但这需要专门的资源和努力。或者,其中一些组织提供评估计划,从而提供软件组织内的优势和需要改进的领域的外部视图。

All the maturity models mentioned here (and others) have benefits, and the essential elements of the models are freely available. However, sometimes the assessment is done by external entities. It’s possible to do an internal self-assessment and define the associated improvement program, but it requires dedicated resources and effort. Alternatively, some of these organizations offer assessment programs, thus providing an external view of the strengths and areas for improvement within a software organization.

18.12 总结

18.12 Summary

所有软件工程师都应该了解开发安全软件需要什么。提高软件产品安全性所需的步骤与软件流程中的每个活动相关,无论使用哪种流程模型。

All software engineers should have an understanding of what it takes to develop secure software. The steps that are needed to improve the security of your software products are relevant in each activity in the software process, regardless of which process model is used.

尽管仍有许多悬而未决的问题和需要进一步研究的技术,但目前有许多资源可以帮助应对这一挑战。对于软件流程中通常发生的每项活动,请尝试纳入安全方面。可以评估 Microsoft SDL 和 SQUARE 模型等模型,以确定可以将哪些步骤合并到开发过程中。第371页

Although there are still many open questions, and technologies that need additional research, there are many resources available today to assist with this challenge. For every activity that normally takes place in the software process, try to incorporate security aspects. Models such as Microsoft SDL and the SQUARE model can be assessed to determine which steps you can incorporate into your development process.Page 371

为风险分析活动增加安全性,尤其是使用 NIST 提供的详细指南。鉴于已有的安全编码标准的数量,任何人当然都有可能学习如何安全地编码。检查您的代码是否存在剩余漏洞。了解如何识别安全漏洞并制定缓解策略并确定其优先级。对您的代码执行静态分析测试。访问 OWASP 和 BSIMM 等网站,了解软件安全工程的成熟度。

Add security to a risk analysis activity, especially using detailed guidance available from NIST. Given the number of secure coding standards already available, it is certainly possible for anyone to learn how to code securely. Inspect your code for remaining vulnerabilities. Learn how to identify security holes and develop and prioritize mitigation strategies. Perform static analysis testing on your code. Visit the OWASP and BSIMM websites, among others, to learn about maturity in software security engineering.

随着软件变得越来越普遍,漏洞和成功黑客攻击的数量也在增加。我们需要尽一切努力来阻止这一趋势,但许多工具已经存在来解决这个问题。未能解决软件安全问题的后果是严重的,而开发安全软件的好处是巨大的。

As software becomes ever more ubiquitous, the number of vulnerabilities and successful hacks grow as well. It will take all our efforts to stem the tide, but many of the tools already exist to tackle this problem. The consequences of failing to address software security are high, and the benefits of developing secure software are huge.

问题与思考点

Problems and Points to Ponder

18.1。软件团队为提高软件安全性可以做的最重要的事情是什么?

18.1. What is the most important thing that a software team can do to improve software security?

18.2. 如果您为您的组织推荐一项提高软件安全性的活动,它会是什么?如果您建议多项活动,考虑到所有活动不太可能立即实施,那么它们是什么?优先级是什么?

18.2. If you were recommending one activity for your organization to improve software security, what would it be? If you were recommending multiple activities, what are they, and what would be the priorities, considering that it’s not likely that all of them will be implemented at once?

18.3。如何将软件安全性整合到现有的流程模型或新的流程模型中?

18.3. How could you incorporate software security into your existing process model or into a new process model?

18.4。与同事坐下来,识别正在开发的软件项目的安全风险。提出缓解策略并确定其优先顺序。

18.4. Sit down with a colleague and identify security risks on a software project that is in development. Come up with mitigation strategies and prioritize them.

18.5。您是否正在收集可用于或重新利用的测量数据来帮助测量软件安全性?如果没有,是否可以为此目的轻松收集数据?

18.5. Are you collecting measurement data that could be used or repurposed to help measure software security? If not, is there data that could easily be collected for this purpose?

18.6。使用互联网找出创建网络钓鱼攻击模式所需的详细信息。

18.6. Use the Internet to find out the details needed to create a phishing attack pattern.

18.7。解释一下如果等到系统完成后再解决安全风险可能会遇到的一些问题。

18.7. Explain some of the problems that might be encountered if you wait until after the system is completed to address security risks.

18.8。使用互联网确定单次身份盗窃事件给消费者带来的平均成本。

18.8. Use the Internet to determine the average cost to the consumer of a single incidence of identity theft.

18.9。考虑您在个人手机上使用的移动应用程序。列出开发人员在开发此类应用程序时应考虑的三到五个安全风险。

18.9. Consider a MobileApp that you make use of on your personal phone. List three to five security risks that developers should consider when developing apps like this one.

18.10。确定账单支付钱包类移动应用程序的安全要求。

18.10. Determine the security requirements of a bill-paying wallet-type MobileApp.

1最近,Microsoft 展示了如何将 SDL 活动与敏捷开发方法集成:https://www.microsoft.com/en-us/SDL/Discover/sdlagile.aspx。

1 More recently, Microsoft has shown how the SDL activities can be integrated with an agile development approach: https://www.microsoft.com/en-us/SDL/Discover/sdlagile.aspx.

2要深入了解,请参阅 SEPA 9/e 网站上提供的资源。

2 To dig deeper, see the resources available at the SEPA 9/e website.

3请参阅 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=485410。

3 See https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=485410.

4请参阅 https://csrc.nist.gov/publications/detail/sp/800-37/rev-1/final。

4 See https://csrc.nist.gov/publications/detail/sp/800-37/rev-1/final.

5有关数据流程图的简要教程可从 https://ratandon.mysite.syr

.edu/cis453/notes/DFD_over_Flowcharts.pdf 下载。

5 A brief tutorial on data flow diagrams can be downloaded from https://ratandon.mysite.syr

.edu/cis453/notes/DFD_over_Flowcharts.pdf.

6请参阅 https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.md。

6 See https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.md.

7请参阅 https://www.owasp.org/index.php/Buffer_overflow_attack。

7 See https://www.owasp.org/index.php/Buffer_overflow_attack.

8请参阅 https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices。

8 See https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices.

9请参阅 https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards。

9 See https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards.

10可在 https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis 找到商用工具列表

10 A list of commercially available tools can be found at https://en.wikipedia.org/wiki/List_of_

tools_for_static_code_analysis.

11请参阅 https://www.bsimm.com/。

11 See https://www.bsimm.com/.

12请参阅 https://www.owasp.org/index.php/OWASP_SAMM_Project。

12 See https://www.owasp.org/index.php/OWASP_SAMM_Project.

13参见 https://cmmiinstitute.com/。

13 See https://cmmiinstitute.com/.

14请参阅 https://cmmiinstitute.com/products/cybermaturity。

14 See https://cmmiinstitute.com/products/cybermaturity.

15请参阅 https://www.owasp.org/index.php/OWASP_SAMM_Project。

15 See https://www.owasp.org/index.php/OWASP_SAMM_Project.

16请参阅 https://www.bsimm.com/。

16 See https://www.bsimm.com/.

第372页

Page 372

章节

chapter

19软件测试——组件级

19 Software Testing—Component Level

软件组件测试包含一种策略,该策略描述了作为测试一部分要执行的步骤、何时计划并执行这些步骤,以及需要多少精力、时间和资源。在测试策略中,软件组件测试实现了一系列组件测试策略,这些策略涉及测试计划、测试用例设计、测试执行以及结果数据收集和评估。本章考虑了组件测试策略和策略。

Software component testing incorporates a strategy that describes the steps to be conducted as part of testing, when these steps are planned and then undertaken, and how much effort, time, and resources will be required. Within the testing strategy, software component testing implements a collection of component testing tactics that address test planning, test-case design, test execution, and resultant data collection and evaluation. Both component testing strategy and tactics are considered in this chapter.

第373页为了有效,组件测试策略应该足够灵活,以促进定制测试方法,但也应该足够严格,以鼓励随着项目的进展进行合理的规划和管理跟踪。组件测试仍然是各个软件工程师的责任。由谁进行测试、工程师如何相互交流结果以及测试何时完成,取决于开发团队采用的软件集成方法和设计理念。

Page 373To be effective, a component testing strategy should be flexible enough to promote a customized testing approach but rigid enough to encourage reasonable planning and management tracking as the project progresses. Component testing remains a responsibility of individual software engineers. Who does the testing, how engineers communicate their results with one another, and when testing is done is determined by the software integration approach and design philosophy adopted by the development team.

这些“方法和哲学”就是我们所说的战略和战术——本章要讨论的主题。在第 20 章中,我们讨论通常最终定义团队开发策略的集成测试技术。

These “approaches and philosophies” are what we call strategy and tactics—topics to be discussed in this chapter. In Chapter 20 we discuss the integration testing techniques that often end up defining the team development strategy.

19.1 软件测试的战略方法

19.1 A Strategic Approach to Software Testing

测试是一组可以提前计划并系统地进行的活动。因此,应该为软件过程定义一个软件测试模板(我们可以在其中放置特定测试用例设计技术和测试方法的一组步骤)。

Testing is a set of activities that can be planned in advance and conducted systematically. For this reason, a template for software testing—a set of steps into which we can place specific test-case design techniques and testing methods—should be defined for the software process.

文献 [Jan16] [Dak14] [Gut15] 中提出了许多软件测试策略。所有这些都为您提供了测试模板,并且都具有以下通用特征:

A number of software testing strategies have been proposed in the literature [Jan16] [Dak14] [Gut15]. All provide you with a template for testing, and all have the following generic characteristics:

  • 为了执行有效的测试,您应该进行技术审查(第 16 章)。通过这样做,可以在测试开始之前消除许多错误。

  • To perform effective testing, you should conduct technical reviews (Chapter 16). By doing this, many errors will be eliminated before testing commences.

  • 测试从组件级别开始,然后“向外”进行整个基于计算机的系统的集成。

  • Testing begins at the component level and works “outward” toward the integration of the entire computer-based system.

  • 不同的测试技术适用于不同的软件工程方法和不同的时间点。

  • Different testing techniques are appropriate for different software engineering approaches and at different points in time.

  • 测试由软件开发人员和(对于大型项目)独立测试组进行。

  • Testing is conducted by the developer of the software and (for large projects) an independent test group.

  • 测试和调试是不同的活动,但调试必须适应任何测试策略。

  • Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.

软件测试策略包含一组策略,这些策略可容纳验证小型源代码段是否已正确实现所需的低级测试以及根据客户需求验证主要系统功能的高级测试。战略应该为从业者提供指导,并为管理者提供一系列里程碑。由于测试策略的步骤发生在截止日期压力开始上升的时候,因此进展必须是可衡量的,并且问题应该尽早浮出水面。

A strategy for software testing incorporates a set of tactics that accommodate the low-level tests necessary to verify that a small source code segment has been correctly implemented as well as high-level tests that validate major system functions against customer requirements. A strategy should provide guidance for the practitioner and a set of milestones for the manager. Because the steps of the test strategy occur at a time when deadline pressure begins to rise, progress must be measurable and problems should surface as early as possible.

19.1.1 验证和确认

19.1.1 Verification and Validation

第374页软件测试是一个更广泛的主题的组成部分,通常称为验证和确认 (V&V)。验证是指确保软件正确实现特定功能的一组任务。验证是指一组不同的任务,确保已构建的软件可追溯至客户需求。Boehm [Boe81] 用另一种方式表述了这一点:

Page 374Software testing is one element of a broader topic that is often referred to as verification and validation (V&V). Verification refers to the set of tasks that ensure that software correctly implements a specific function. Validation refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements. Boehm [Boe81] states this another way:

验证:“我们构建的产品正确吗?”

Verification: “Are we building the product right?”

验证:“我们正在构建正确的产品吗?”

Validation: “Are we building the right product?”

V&V 的定义包含许多软件质量保证活动(第 19 章)。1

The definition of V&V encompasses many software quality assurance activities (Chapter 19).1

验证和确认包括广泛的 SQA 活动:技术审查、质量和配置审核、性能监控、模拟、可行性研究、文档审查、数据库审查、算法分析、开发测试、可用性测试、资格测试、验收测试和安装测试。尽管测试在 V&V 中发挥着极其重要的作用,但许多其他活动也是必要的。

Verification and validation include a wide array of SQA activities: technical reviews, quality and configuration audits, performance monitoring, simulation, feasibility study, documentation review, database review, algorithm analysis, development testing, usability testing, qualification testing, acceptance testing, and installation testing. Although testing plays an extremely important role in V&V, many other activities are also necessary.

测试确实提供了评估质量的最后堡垒,更务实的是,可以发现错误。但测试不应被视为安全网。正如他们所说,“你无法测试质量。如果在开始测试之前它不存在,那么当您完成测试时它也不会存在。” 质量在整个软件工程过程中都融入到软件中,测试不能作为过程结束时的修复。方法和工具的正确应用、有效的技术审查以及可靠的管理和测量都会导致测试过程中确认的质量。

Testing does provide the last bastion from which quality can be assessed and, more pragmatically, errors can be uncovered. But testing should not be viewed as a safety net. As they say, “You can’t test in quality. If it’s not there before you begin testing, it won’t be there when you’re finished testing.” Quality is incorporated into software throughout the process of software engineering, and testing cannot be applied as a fix at the end of the process. Proper application of methods and tools, effective technical reviews, and solid management and measurement all lead to quality that is confirmed during testing.

19.1.2 组织软件测试

19.1.2 Organizing for Software Testing

对于每个软件项目来说,测试开始时都会存在固有的利益冲突。现在要求构建该软件的人测试该软件。这本身似乎是无害的。毕竟,谁比它的开发人员更了解该程序呢?不幸的是,这些开发人员的既得利益在于证明该程序没有错误,它可以根据客户的要求工作,并且它将在预算内按时完成。这些利益中的每一个都会削弱彻底的测试。

For every software project, there is an inherent conflict of interest that occurs as testing begins. The people who have built the software are now asked to test the software. This seems harmless in itself; after all, who knows the program better than its developers? Unfortunately, these same developers have a vested interest in demonstrating that the program is error-free, that it works according to customer requirements, and that it will be completed on schedule and within budget. Each of these interests mitigates against thorough testing.

从心理学的角度来看,软件分析和设计(以及编码)是建设性的任务。软件工程师分析、建模,然后创建计算机程序及其文档。与任何建造者一样,软件工程师对所建造的大厦感到自豪,并对任何试图拆毁它的人表示怀疑。当测试开始时,会有一种微妙但明确的尝试“破坏”软件工程师所构建的东西。从构建者的角度来看,测试可以被认为是(心理上)破坏性的。因此,构建者要小心行事,设计和执行测试来证明程序可以正常工作,而不是发现错误。不幸的是,错误仍然存​​在。而且,即使软件工程师找不到它们,客户也会找到!

From a psychological point of view, software analysis and design (along with coding) are constructive tasks. The software engineer analyzes, models, and then creates a computer program and its documentation. Like any builder, the software engineer is proud of the edifice that has been built and looks askance at anyone who attempts to tear it down. When testing commences, there is a subtle, yet definite, attempt to “break” the thing that the software engineer has built. From the point of view of the builder, testing can be considered to be (psychologically) destructive. So the builder treads lightly, designing and executing tests that will demonstrate that the program works, rather than to uncover errors. Unfortunately, errors will be nevertheless present. And, if the software engineer doesn’t find them, the customer will!

第375页从前面的讨论中您可能会推断出许多误解:(1)软件开发人员根本不应该进行测试,(2)软件应该“扔到墙上”给愿意测试的陌生人(3)测试人员只有在测试步骤即将开始时才参与项目。这些陈述中的每一个都是不正确的。

Page 375There are often a number of misconceptions that you might infer from the preceding discussion: (1) that the developer of software should do no testing at all, (2) that the software should be “tossed over the wall” to strangers who will test it mercilessly, and (3) that testers get involved with the project only when the testing steps are about to begin. Each of these statements is incorrect.

软件开发人员始终负责测试程序的各个单元(组件),确保每个单元执行其设计的功能或表现出其设计的行为。在许多情况下,开发人员还会进行集成测试,这是一个导致完整软件架构构建(和测试)的测试步骤。只有在软件架构完成后,独立的测试小组才会介入。

The software developer is always responsible for testing the individual units (components) of the program, ensuring that each performs the function or exhibits the behavior for which it was designed. In many cases, the developer also conducts integration testing—a testing step that leads to the construction (and test) of the complete software architecture. Only after the software architecture is complete does an independent test group become involved.

独立测试组(ITG)的作用是消除与让构建者测试已构建的事物相关的固有问题。独立测试消除了可能存在的利益冲突。毕竟,ITG 人员是拿钱来发现错误的。

The role of an independent test group (ITG) is to remove the inherent problems associated with letting the builder test the thing that has been built. Independent testing removes the conflict of interest that may otherwise be present. After all, ITG personnel are paid to find errors.

但是,您不能将项目移交给 ITG 并走开。开发人员和 ITG 在整个软件项目中密切合作,以确保进行彻底的测试。在进行测试时,开发人员必须能够纠正发现的错误。

However, you don’t turn the program over to ITG and walk away. The developer and the ITG work closely throughout a software project to ensure that thorough tests will be conducted. While testing is conducted, the developer must be available to correct errors that are uncovered.

ITG 是软件开发项目团队的一部分,因为它参与分析和设计,并在整个大型项目中保持参与(规划和指定测试程序)。然而,在许多情况下,ITG 向软件质量保证组织报告,从而实现一定程度的独立性,而如果它是软件工程团队的一部分,这是不可能实现的。

The ITG is part of the software development project team in the sense that it becomes involved during analysis and design and stays involved (planning and specifying test procedures) throughout a large project. However, in many cases the ITG reports to the software quality assurance organization, thereby achieving a degree of independence that might not be possible if it were a part of the software engineering team.

19.1.3 总体情况

19.1.3 The Big Picture

软件流程可以被视为如图 19.1所示的螺旋。最初,系统工程定义软件的角色并导致软件需求分析,其中建立软件的信息域、功能、行为、性能、约束和验证标准。沿着螺旋向内移动,你开始设计,最后开始编码。为了开发计算机软件,你沿着流线螺旋向内,每转一圈都会降低抽象级别。第376页

The software process may be viewed as the spiral illustrated in Figure 19.1. Initially, system engineering defines the role of software and leads to software requirements analysis, where the information domain, function, behavior, performance, constraints, and validation criteria for software are established. Moving inward along the spiral, you come to design and finally to coding. To develop computer software, you spiral inward along streamlines that decrease the level of abstraction on each turn.Page 376

图19.1测试 策略

Figure 19.1 Testing strategy

软件测试策略也可以在螺旋的背景下看待(图19.1)。单元测试从螺旋的漩涡开始,集中于源代码中实现的软件的每个单元(例如,组件、类或WebApp 内容对象)。测试的进展是沿着螺旋向外发展到集成测试,其重点是软件架构的设计和构建。在螺旋上再向外转,您会遇到验证测试,其中作为需求建模的一部分建立的需求将根据已构建的软件进行验证。最后,进行系统测试,将软件和其他系统元素作为一个整体进行测试。为了测试计算机软件,您需要沿着流程螺旋式推进,每转一圈都会扩大测试范围。

A strategy for software testing may also be viewed in the context of the spiral (Figure 19.1). Unit testing begins at the vortex of the spiral and concentrates on each unit (e.g., component, class, or WebApp content object) of the software as implemented in source code. Testing progresses by moving outward along the spiral to integration testing, where the focus is on design and the construction of the software architecture. Taking another turn outward on the spiral, you encounter validation testing, where requirements established as part of requirements modeling are validated against the software that has been constructed. Finally, you arrive at system testing, where the software and other system elements are tested as a whole. To test computer software, you spiral out along streamlines that broaden the scope of testing with each turn.

从程序的角度考虑该过程,软件工程背景下的测试实际上是一系列按顺序实施的四个步骤。步骤如图19.2所示。最初,测试分别关注每个组件,确保其作为一个单元正常运行。因此,名称为单元测试。单元测试大量使用测试技术来执行组件控制结构中的特定路径,以确保完全覆盖和最大程度的错误检测。接下来,必须组装或集成组件以形成完整的软件包。集成测试解决与验证和程序构建的双重问题相关的问题。尽管可以使用执行特定程序路径的技术来确保覆盖主要控制路径,但注重输入和输出的测试用例设计技术在集成过程中更为普遍。软件集成(构建)后,将进行一组高阶测试。必须评估验证标准(在需求分析期间建立)。验证测试提供了软件满足所有功能、行为和性能要求的最终保证。第377页

Considering the process from a procedural point of view, testing within the context of software engineering is actually a series of four steps that are implemented sequentially. The steps are shown in Figure 19.2. Initially, tests focus on each component individually, ensuring that it functions properly as a unit. Hence, the name unit testing. Unit testing makes heavy use of testing techniques that exercise specific paths in a component’s control structure to ensure complete coverage and maximum error detection. Next, components must be assembled or integrated to form the complete software package. Integration testing addresses the issues associated with the dual problems of verification and program construction. Test-case design techniques that focus on inputs and outputs are more prevalent during integration, although techniques that exercise specific program paths may be used to ensure coverage of major control paths. After the software has been integrated (constructed), a set of high-order tests is conducted. Validation criteria (established during requirements analysis) must be evaluated. Validation testing provides final assurance that software meets all functional, behavioral, and performance requirements.Page 377

图19.2软件 测试步骤

Figure 19.2 Software testing steps

最后一个高阶测试步骤超出了软件工程的范围,并进入了更广泛的计算机系统工程背景(第21 章中讨论)。软件一旦经过验证,必须与其他系统元素(例如硬件、人员、数据库)相结合。系统测试验证所有元素是否正确啮合以及是否实现了整体系统功能和性能。

The last high-order testing step falls outside the boundary of software engineering and into the broader context of computer system engineering (discussed in Chapter 21). Software, once validated, must be combined with other system elements (e.g., hardware, people, databases). System testing verifies that all elements mesh properly and that overall system function and performance is achieved.

19.1.4 “完成”的标准

19.1.4 Criteria for “Done”

每次讨论软件测试时都会出现一个经典问题:“我们什么时候完成测试——我们如何知道我们已经进行了足够的测试?” 遗憾的是,这个问题没有明确的答案,但有一些务实的回应和经验指导的早期尝试。第378页

A classic question arises every time software testing is discussed: “When are we done testing—how do we know that we’ve tested enough?” Sadly, there is no definitive answer to this question, but there are a few pragmatic responses and early attempts at empirical guidance.Page 378

对这个问题的一种回答是:“你永远不会完成测试;负担只是从您(软件工程师)转移到最终用户。” 每次用户执行计算机程序时,该程序都在被测试。这一发人深省的事实强调了其他软件质量保证活动的重要性。另一种回应(有点愤世嫉俗,但仍然准确)是:“当你没时间或没钱时,你就完成了测试。”

One response to the question is: “You’re never done testing; the burden simply shifts from you (the software engineer) to the end user.” Every time the user executes a computer program, the program is being tested. This sobering fact underlines the importance of other software quality assurance activities. Another response (somewhat cynical but nonetheless accurate) is: “You’re done testing when you run out of time or you run out of money.”

尽管很少有从业者会反对这些回应,但您需要更严格的标准来确定何时进行了足够的测试。统计质量保证方法(第 17.6 节)提出了统计使用技术 [Rya11],该技术执行一系列测试,这些测试源自目标人群中所有用户的所有可能程序执行的统计样本。通过在软件测试期间收集指标并利用现有的统计模型,可以制定有意义的指南来回答以下问题:“我们什么时候完成测试?”

Although few practitioners would argue with these responses, you need more rigorous criteria for determining when sufficient testing has been conducted. The statistical quality assurance approach (Section 17.6) suggests statistical use techniques [Rya11] that execute a series of tests derived from a statistical sample of all possible program executions by all users from a targeted population. By collecting metrics during software testing and making use of existing statistical models, it is possible to develop meaningful guidelines for answering the question: “When are we done testing?”

19.2 规划和记录保存

19.2 Planning and Recordkeeping

许多策略可用于测试软件。一种极端的情况是,你可以等到系统完全构建完成,然后对整个系统进行测试,以期发现错误。这种方法虽然很有吸引力,但根本行不通。它将导致软件有缺陷,让所有利益相关者失望。在另一个极端,您可以每天在构建系统的任何部分时进行测试。

Many strategies can be used to test software. At one extreme, you can wait until the system is fully constructed and then conduct tests on the overall system in the hope of finding errors. This approach, although appealing, simply does not work. It will result in buggy software that disappoints all stakeholders. At the other extreme, you could conduct tests on a daily basis, whenever any part of the system is constructed.

许多软件团队选择的测试策略(以及我们推荐的测试策略)介于两个极端之间。它采用渐进式的测试观点,从单个程序单元的测试开始,转向旨在促进单元集成的测试(有时每天进行),最后以随着构建的系统的发展而进行的测试结束。本章的其余部分将重点讨论组件级测试和测试用例设计。

A testing strategy that is chosen by many software teams (and the one we recommend) falls between the two extremes. It takes an incremental view of testing, beginning with the testing of individual program units, moving to tests designed to facilitate the integration of the units (sometimes on a daily basis), and culminating with tests that exercise the constructed system as it evolves. The remainder of this chapter will focus on component-level testing and test-case design.

单元测试将验证工作集中在软件设计的最小单元——软件组件或模块上。使用组件级设计描述作为指导,测试重要的控制路径以发现模块边界内的错误。测试的相对复杂性和这些测试发现的错误受到为单元测试建立的约束范围的限制。单元测试侧重于组件边界内的内部处理逻辑和数据结构。这种类型的测试可以对多个组件并行进行。

Unit testing focuses verification effort on the smallest unit of software design—the software component or module. Using the component-level design description as a guide, important control paths are tested to uncover errors within the boundary of the module. The relative complexity of tests and the errors those tests uncover is limited by the constrained scope established for unit testing. The unit test focuses on the internal processing logic and data structures within the boundaries of a component. This type of testing can be conducted in parallel for multiple components.

如果一系列压倒性的问题得不到解决,那么最好的策略也会失败。Tom Gilb [Gil95] 认为,只有当软件测试人员满足以下条件时,软件测试策略才会成功:(1) 在测试开始之前就以可量化的方式指定产品需求,(2) 明确说明测试目标,(3) 了解软件的用户并为每个用户类别开发一个配置文件,(4) 开发一个强调“快速周期测试”的测试计划,2 (5) 构建旨在测试自身的“强大”软件(反窃听的概念在第28 章中简要讨论) )用于测试过程。第379页

The best strategy will fail if a series of overriding issues are not addressed. Tom Gilb [Gil95] argues that a software testing strategy will succeed only when software testers: (1) specify product requirements in a quantifiable manner long before testing commences, (2) state testing objectives explicitly, (3) understand the users of the software and develop a profile for each user category, (4) develop a testing plan that emphasizes “rapid cycle testing,”2 (5) build “robust” software that is designed to test itself (the concept of antibugging is discussed briefly in Chapter 28) for the testing process.Page 379

这些原则也反映在敏捷软件测试中。在敏捷开发中,测试计划需要在第一次冲刺会议之前制定并由利益相关者审查。该计划仅列出了粗略的时间表、标准和要使用的工具。在创建实现每个用户故事所需的代码时,利益相关者会开发和审查测试用例及其使用说明。测试结果会尽快与所有团队成员共享,以便对现有和未来的代码开发进行更改。因此,许多团队选择将测试记录保存在在线文档中。

These principles are reflected in agile software testing as well. In agile development, the test plan needs to be established before the first sprint meeting and reviewed by stakeholders. This plan merely lays out the rough time line, standards, and tools to be used. The test cases and directions for their use are developed and reviewed by the stakeholders as the code needed to implement each user story is created. Testing results are shared with all team members as soon as practical to allow changes in both existing and future code development. For this reason, many teams choose to keep their test recordkeeping in online documents.

测试记录保存不需要很麻烦。测试用例可以记录在 Google Docs 电子表格中,该电子表格简要描述了测试用例,包含指向正在测试的需求的指针,包含测试用例数据的预期输出或成功标准,允许测试人员指示测试是否通过或失败以及测试用例运行的日期,并且应该有空间评论为什么测试可能无法帮助调试。这种在线表格可以根据需要查看进行分析,并且很容易在团队会议上进行总结。测试用例设计问题在19.3 节中讨论。

Test recordkeeping does not need to be burdensome. The test cases can be recorded in a Google Docs spreadsheet that briefly describes the test case, contains a pointer to the requirement being tested, contains expected output from the test case data or the criteria for success, allows testers to indicate whether the test was passed or failed and the dates the test case was run, and should have room for comments about why a test may have failed to aid in debugging. This type of online form can be viewed as needed for analysis, and it is easy to summarize at team meetings. Test-case design issues are discussed in Section 19.3.

19.2.1 脚手架的作用

19.2.1 Role of Scaffolding

组件测试通常被视为编码步骤的辅助手段。单元测试的设计可以在编码开始之前或生成源代码之后进行。对设计信息的审查为建立可能发现错误的测试用例提供了指导。每个测试用例都应该与一组预期结果相结合。

Component testing is normally considered as an adjunct to the coding step. The design of unit tests can occur before coding begins or after source code has been generated. A review of design information provides guidance for establishing test cases that are likely to uncover errors. Each test case should be coupled with a set of expected results.

由于组件不是独立的程序,因此需要某种类型的脚手架来创建测试框架。作为该框架的一部分,通常必须为每个单元测试开发驱动程序和/或存根软件。单元测试环境如图 19.3所示。在大多数应用程序中,驱动程序只不过是一个“主程序”,它接受测试用例数据,将这些数据传递给组件(要测试),并打印相关结果。存根用于替换从属于要测试的组件(由其调用)的模块。存根或“虚拟子程序”使用从属模块的接口,可以进行最少的数据操作,打印条目验证,并将控制权返回到正在进行测试的模块

Because a component is not a stand-alone program, some type of scaffolding is required to create a testing framework. As part of this framework, driver and/or stub software must often be developed for each unit test. The unit-test environment is illustrated in Figure 19.3. In most applications a driver is nothing more than a “main program” that accepts test-case data, passes such data to the component (to be tested), and prints relevant results. Stubs serve to replace modules that are subordinate (invoked by) the component to be tested. A stub or “dummy subprogram” uses the subordinate module’s interface, may do minimal data manipulation, prints verification of entry, and returns control to the module undergoing testing.

19.3 单元测试环境

Figure 19.3 Unit-test environment

驱动程序和存根代表测试“开销”。也就是说,两者都是必须编码的软件(通常不应用正式设计),但不随最终软件产品一起交付。如果驱动程序和存根保持简单,实际开销相对较低。不幸的是,许多组件无法使用“简单”的脚手架软件进行充分的单元测试。在这种情况下,完整的测试可以推迟到集成测试步骤(也使用驱动程序或存根)。

Drivers and stubs represent testing “overhead.” That is, both are software that must be coded (formal design is not commonly applied) but that is not delivered with the final software product. If drivers and stubs are kept simple, actual overhead is relatively low. Unfortunately, many components cannot be adequately unit-tested with “simple” scaffolding software. In such cases, complete testing can be postponed until the integration test step (where drivers or stubs are also used).

19.2.2 经济高效的测试

19.2.2 Cost-Effective Testing

详尽的测试要求被测试的组件处理输入值和测试用例顺序的每种可能的组合(例如,考虑计算机国际象棋游戏中的移动生成器)。在某些情况下,这需要创建近乎无限数量的数据集。详尽测试的回报通常不值得付出努力,因为单独的测试不能用来证明组件是否正确实现。在某些情况下,您没有资源进行全面的单元测试。在这些情况下,测试人员应该选择对项目成功至关重要的模块以及那些被怀疑容易出错的模块,因为它们将复杂性指标作为单元测试的重点。第 19.4 节19.6节讨论了一些用于最大限度地减少做好测试所需的测试用例数量的技术。第380页

Exhaustive testing requires every possible combination of input values and test-case orderings be processed by the component being tested (e.g., consider the move generator in a computer chess game). In some cases, this would require the creation of a near-infinite number of data sets. The return on exhaustive testing is often not worth the effort, since testing alone cannot be used to prove a component is correctly implemented. There are some situations in which you will not have the resources to do comprehensive unit testing. In these cases, testers should select modules crucial to the success of the project and those that are suspected to be error-prone because they have complexity metrics as the focus for your unit testing. Some techniques for minimizing the number of test cases required to do a good job testing are discussed in Section 19.4 through 19.6.Page 380

第381页

Page 381

19.3 测试用例设计

19.3 Test-Case Design

在开发组件代码之前设计单元测试用例是一个好主意。这确保您开发的代码将通过测试或至少是您已经想到的测试。

It is a good idea to design unit test cases before you develop code for a component. This ensures that you’ll develop code that will pass the tests or at least the tests you thought of already.

单元测试如图 19.4所示。模块接口经过测试,以确保信息正确流入和流出被测程序单元(第 19.5.1 节)。检查本地数据结构以确保临时存储的数据在算法执行的所有步骤中保持其完整性。通过控制结构的所有独立路径都被执行,以确保模块中的所有语句至少被执行一次(第 19.4.2 节)。测试边界条件以确保模块在为限制或约束处理而建立的边界处正常运行(第 19.5.3 节)。最后,测试所有错误处理路径。

Unit tests are illustrated schematically in Figure 19.4. The module interface is tested to ensure that information properly flows into and out of the program unit under test (Section 19.5.1). Local data structures are examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithm’s execution. All independent paths through the control structure are exercised to ensure that all statements in a module have been executed at least once (Section 19.4.2). Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing (Section 19.5.3). And finally, all error-handling paths are tested.

图19.4单元 测试

Figure 19.4 Unit test

在启动任何其他测试之前,先测试跨组件接口的数据流。如果数据不能正确输入和退出,所有其他测试都没有意义。此外,应在单元测试期间使用本地数据结构,并应确定(如果可能)本地对全局数据的影响。

Data flow across a component interface is tested before any other testing is initiated. If data do not enter and exit properly, all other tests are moot. In addition, local data structures should be exercised and the local impact on global data should be ascertained (if possible) during unit testing.

执行路径的选择性测试是单元测试期间的一项重要任务。测试用例的设计应能够发现由于错误计算、不正确比较或不正确控制流而导致的错误。

Selective testing of execution paths is an essential task during the unit test. Test cases should be designed to uncover errors due to erroneous computations, incorrect comparisons, or improper control flow.

边界测试是最重要的单元测试任务之一。软件经常在其边界处失败。也就是说,当处理n维数组的第 n个元素时、当调用i次循环的第 i次重复时、或者当遇到最大或最小允许值时,通常会发生错误。测试数据结构、控制流以及略低于、略高于和略高于最大值和最小值的数据值的测试用例很可能发现错误。第382页

Boundary testing is one of the most important unit-testing tasks. Software often fails at its boundaries. That is, errors often occur when the nth element of an n-dimensional array is processed, when the ith repetition of a loop with i passes is invoked, or when the maximum or minimum allowable value is encountered. Test cases that exercise data structure, control flow, and data values just below, at, and just above maxima and minima are very likely to uncover errors.Page 382

良好的设计可以预见错误情况并建立错误处理路径,以便在发生错误时重新路由或干净地终止处理。Yourdon [You75] 称这种方法为反窃听。不幸的是,有一种趋势是将错误处理合并到软件中,然后从不测试错误处理。确保您设计的测试能够执行每个错误处理路径。如果不这样做,该路径在调用时可能会失败,从而加剧本已危险的情况。

A good design anticipates error conditions and establishes error-handling paths to reroute or cleanly terminate processing when an error does occur. Yourdon [You75] calls this approach antibugging. Unfortunately, there is a tendency to incorporate error handling into software and then never test the error handling. Be sure that you design tests to execute every error-handling path. If you don’t, the path may fail when it is invoked, exacerbating an already dicey situation.

评估错误处理时应测试的潜在错误包括:(1) 错误描述难以理解,(2) 注意到的错误与遇到的错误不对应,(3) 错误条件导致系统在错误处理之前进行干预,(4) ) 异常条件处理不正确,或者 (5) 错误描述没有提供足够的信息来协助定位错误原因。

Among the potential errors that should be tested when error handling is evaluated are: (1) error description is unintelligible, (2) error noted does not correspond to error encountered, (3) error condition causes system intervention prior to error handling, (4) exception-condition processing is incorrect, or (5) error description does not provide enough information to assist in the location of the cause of the error.

19.3.1 需求和用例

19.3.1 Requirements and Use Cases

在需求工程(第 7 章)中,我们建议通过与客户合作生成用户故事来开始需求收集过程,开发人员可以将这些故事细化为正式的用例和分析模型。这些用例和模型可用于指导测试用例的系统创建,这些测试用例可以很好地测试每个软件组件的功能需求,并提供良好的整体测试覆盖率[Gut15]。

In requirements engineering (Chapter 7) we suggested starting the requirements gathering process by working with the customers to generate user stories that developers can refine into formal use cases and analysis models. These use cases and models can be used to guide the systematic creation of test cases that do a good job of testing the functional requirements of each software component and provide good test coverage overall [Gut15].

第383页分析工件并不能深入了解许多非功能性需求(例如,可用性或可靠性)的测试用例的创建。这是用户故事中包含的客户验收声明可以形成为与组件相关的非功能性需求编写测试用例的基础。测试用例开发人员根据其专业经验使用附加信息来量化验收标准以使其可测试。测试非功能性需求可能需要使用集成测试方法(第20章)或其他专门的测试技术(第21章)。

Page 383The analysis artifacts do not provide much insight into the creation of test cases for many nonfunctional requirements (e.g., usability or reliability). This is where the customer’s acceptance statements included in the user stories can form the basis for writing test cases for the nonfunctional requirements associated with components. Test-case developers make use of additional information based on their professional experience to quantify acceptance criteria to make it testable. Testing nonfunctional requirements may require the use of integration testing methods (Chapter 20) or other specialized testing techniques (Chapter 21).

测试的主要目的是帮助开发人员发现以前未知的缺陷。执行证明组件正确运行的测试用例通常还不够好。正如我们之前提到的(第 19.3 节),编写测试用例来锻炼组件的错误处理能力非常重要。但是,如果我们要发现新的缺陷,那么编写测试用例来测试组件是否不会执行不应该执行的操作(例如,在没有适当权限的情况下访问特权数据源)也很重要。这些可以正式表述为反要求3,并且可能需要专门的安全测试技术(第 21.7 节)[Ale17]。应包含这些所谓的负面测试用例,以确保组件的行为符合客户的期望。

The primary purpose of testing is to help developers discover defects that were previously unknown. Executing test cases that demonstrate the component is running correctly is often not good enough. As we mentioned earlier (Section 19.3), it is important to write test cases that exercise the error-handling capabilities of a component. But if we are to uncover new defects, it is also important to write test cases to test that a component does not do things it is not supposed to do (e.g., accessing privileged data sources without proper permissions). These may be stated formally as anti-requirements3 and may require specialized security testing techniques (Section 21.7) [Ale17]. These so-called negative test cases should be included to make sure the component behaves according to the customer’s expectations.

19.3.2 可追溯性

19.3.2 Traceability

为了确保测试过程是可审计的,每个测试用例都需要可追溯到特定的功能或非功能需求或反需求。通常,非功能性需求需要追溯到特定的业务或架构需求。许多敏捷开发人员抵制可追溯性的概念,认为这给开发人员带来了不必要的负担。但许多测试过程失败可以追溯到缺少可追溯性路径、不一致的测试数据或不完整的测试覆盖范围 [Rem14]。回归测试(第 20 章中讨论)确保测试用例可追溯到需求,这是重要的第一步,需要在组件测试期间完成。

To ensure that the testing process is auditable, each test case needs to be traceable back to specific functional or nonfunctional requirements or anti-requirements. Often nonfunctional requirements need to be traceable to specific business or architectural requirements. Many agile developers resist the concept of traceability as an unnecessary burden on developers. But many test process failures can be traced to missing traceability paths, inconsistent test data, or incomplete test coverage [Rem14]. Regression testing (discussed in Chapter 20), making sure that test cases are traceable to requirements is an important first step and needs to be done during component testing.

19.4 白盒测试

19.4 White-Box Testing

白盒测试,有时称为玻璃盒测试或结构测试,是一种测试用例设计理念,它使用描述为组件级设计一部分的控制结构来派生测试用例。使用白盒测试方法,您可以派生测试用例,以(1)保证模块内的所有独立路径至少被执行一次,(2)在正确和错误的方面执行所有逻辑决策,(3)执行所有在其边界和操作范围内进行循环,以及 (4) 运用内部数据结构以确保其有效性。第384页

White-box testing, sometimes called glass-box testing or structural testing, is a test-case design philosophy that uses the control structure described as part of component-level design to derive test cases. Using white-box testing methods, you can derive test cases that (1) guarantee that all independent paths within a module have been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise internal data structures to ensure their validity.Page 384

19.4.1 基础路径测试

19.4.1 Basis Path Testing

基本路径测试是一种白盒测试技术,由 Tom McCabe [McC76] 首先提出。基本路径方法使测试用例设计者能够导出程序设计的逻辑复杂性度量,并使用该度量作为定义执行路径的基本集的指南。为运用基础集而派生的测试用例保证在测试期间至少执行一次程序中的每条语句。

Basis path testing is a white-box testing technique first proposed by Tom McCabe [McC76]. The basis path method enables the test-case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

在引入基本路径方法之前,必须引入一种用于表示控制流的简单符号,称为流程图(或程序图)。4只有当组件的逻辑结构比较复杂时才应绘制流程图。流程图使您可以更轻松地跟踪程序路径。

Before the basis path method can be introduced, a simple notation for the representation of control flow, called a flow graph (or program graph), must be introduced.4 A flow graph should be drawn only when the logical structure of a component is complex. The flow graph allows you to trace program paths more readily.

为了说明流程图的使用,请考虑图 19.5a中的程序设计表示。这里用流程图来描述程序的控制结构。图 19.5b将流程图映射到相应的流程图(假设流程图的决策菱形中不包含复合条件)。参考图 19.5b,每个圆圈称为流程图节点,代表一个或多个程序语句。一系列流程框和决策菱形可以映射到单个节点。流程图上的箭头称为链接,表示控制流,类似于流程图箭头。边必须终止于节点,即使该节点不表示任何过程语句(例如,请参阅 if-then-else 构造的流程图符号)。由边和节点界定的区域称为区域。在计算区域时,我们将图形之外的区域也算作区域。

To illustrate the use of a flow graph, consider the procedural design representation in Figure 19.5a. Here, a flowchart is used to depict program control structure. Figure 19.5b maps the flowchart into a corresponding flow graph (assuming that no compound conditions are contained in the decision diamonds of the flowchart). Referring to Figure 19.5b, each circle, called a flow graph node, represents one or more procedural statements. A sequence of process boxes and a decision diamond can map into a single node. The arrows on the flow graph, called edges or links, represent flow of control and are analogous to flowchart arrows. An edge must terminate at a node, even if the node does not represent any procedural statements (e.g., see the flow graph symbol for the if-then-else construct). Areas bounded by edges and nodes are called regions. When counting regions, we include the area outside the graph as a region.

图19.5 (a)流程图 和(b)流程图

Figure 19.5 (a) Flowchart and (b) flow graph

独立路径是通过程序引入至少一组新处理语句或新条件的任何路径。当用流程图表示时,独立路径必须沿着至少一条在定义路径之前尚未遍历的边移动。例如,图 19.5b所示流程图的一组独立路径是第385页

An independent path is any path through the program that introduces at least one new set of processing statements or a new condition. When stated in terms of a flow graph, an independent path must move along at least one edge that has not been traversed before the path is defined. For example, a set of independent paths for the flow graph illustrated in Figure 19.5b isPage 385

路径 1:1-11

Path 1: 1-11

路径 2:1-2-3-4-5-10-1-11

Path 2: 1-2-3-4-5-10-1-11

路径 3:1-2-3-6-8-9-10-1-11

Path 3: 1-2-3-6-8-9-10-1-11

路径 4:1-2-3-6-7-9-10-1-11

Path 4: 1-2-3-6-7-9-10-1-11

请注意,每条新路径都会引入一条新边。路径

Note that each new path introduces a new edge. The path

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

1-2-3-4-5-10-1-2-3-6-8-9-10-1-11

不被视为独立路径,因为它只是已指定路径的组合并且不遍历任何新边。

is not considered to be an independent path because it is simply a combination of already specified paths and does not traverse any new edges.

路径 1 到 4 构成图 19.5b中流程图的基础集。也就是说,如果您可以设计测试来强制执行这些路径(一个基础集),则程序中的每个语句都将保证至少被执行一次,并且每个条件都将在其正确和错误的方面都被执行。应该注意的是,基组不是唯一的。事实上,对于给定的程序设计可以导出许多不同的基础集。

Paths 1 through 4 constitute a basis set for the flow graph in Figure 19.5b. That is, if you can design tests to force execution of these paths (a basis set), every statement in the program will have been guaranteed to be executed at least one time and every condition will have been executed on its true and false sides. It should be noted that the basis set is not unique. In fact, a number of different basis sets can be derived for a given procedural design.

你怎么知道要寻找多少条路径?圈复杂度的计算提供了答案。圈复杂度是一种软件度量,可定量测量程序的逻辑复杂度。当在基本路径测试方法的上下文中使用时,为圈复杂度计算的值定义了程序的基本集中独立路径的数量,并为您提供了必须进行的测试数量的上限,以确保所有语句至少被执行一次。

How do you know how many paths to look for? The computation of cyclomatic complexity provides the answer. Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. When used in the context of the basis path testing method, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program and provides you with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.

圈复杂度以图论为基础,为您提供了非常有用的软件度量。复杂度通过以下三种方式之一计算:

Cyclomatic complexity has a foundation in graph theory and provides you with an extremely useful software metric. Complexity is computed in one of three ways:

  1. 流图的区域数量对应于圈复杂度。

  2. The number of regions of the flow graph corresponds to the cyclomatic complexity.

  3. 流程图G的圈复杂度V ( G )定义为

    V ( G ) = EN + 2

    其中E是流图边的数量,N是流图节点的数量。

  4. Cyclomatic complexity V(G) for a flow graph G is defined as

    V(G) = EN + 2

    where E is the number of flow graph edges and N is the number of flow graph nodes.

  5. 流程图G的循环复杂度V ( G )也定义为

    V ( G ) = P + 1

    其中P是流图G中包含的谓词节点的数量。

  6. Cyclomatic complexity V(G) for a flow graph G is also defined as

    V(G) = P + 1

    where P is the number of predicate nodes contained in the flow graph G.

再次参考图 19.5b中的流程图,可以使用刚才提到的每种算法来计算圈复杂度:

Referring once more to the flow graph in Figure 19.5b, the cyclomatic complexity can be computed using each of the algorithms just noted:

  1. 流程图有四个区域。

  2. The flow graph has four regions.

  3. V ( G ) = 11 条边 – 9 个节点 + 2 = 4。

  4. V(G) = 11 edges – 9 nodes + 2 = 4.

  5. V ( G ) = 3 谓词边 + 1 = 4。

  6. V(G) = 3 predicate edges + 1 = 4.

第386页因此,图19.5b中流程图的圈复杂度为4。

Page 386Therefore, the cyclomatic complexity of the flow graph in Figure 19.5b is 4.

更重要的是, V ( G )的值为您提供了构成基础集的独立路径数量的上限,并且隐含着为保证覆盖范围而必须设计和执行的测试数量的上限。所有程序语句。因此,在这种情况下,我们需要定义最多四个测试用例来测试每个独立的逻辑路径。

More important, the value for V(G) provides you with an upper bound for the number of independent paths that form the basis set and, by implication, an upper bound on the number of tests that must be designed and executed to guarantee coverage of all program statements. So in this case we would need to define at most four test cases to exercise each independent logic path.

19.4.2 控制结构测试

19.4.2 Control Structure Testing

第 19.4.1 节中描述的基本路径测试技术是控制结构测试的多种技术之一。尽管基本路径测试简单且高效,但其本身还不够。在本节中,讨论控制结构测试的其他变化。这些扩大了测试覆盖范围并提高了白盒测试的质量。

The basis path testing technique described in Section 19.4.1 is one of a number of techniques for control structure testing. Although basis path testing is simple and highly effective, it is not sufficient in itself. In this section, other variations on control structure testing are discussed. These broaden testing coverage and improve the quality of white-box testing.

条件测试[Tai89]是一种测试用例设计方法,用于测试程序模块中包含的逻辑条件。数据流测试[Fra93]根据程序中变量的定义位置和使用来选择程序的测试路径。

Condition testing [Tai89] is a test-case design method that exercises the logical conditions contained in a program module. Data flow testing [Fra93] selects test paths of a program according to the locations of definitions and uses of variables in the program.

第387页循环测试是一种白盒测试技术,专门关注循环结构的有效性。可以定义两种不同类型的循环[Bei90]:简单循环和嵌套循环。(图19.6)。

Page 387Loop testing is a white-box testing technique that focuses exclusively on the validity of loop constructs. Two different classes of loops [Bei90] can be defined: simple loops and nested loops. (Figure 19.6).

图19.6循环 的类别

Figure 19.6 Classes of loops

简单的循环。以下一组测试可应用于简单循环,其中n是允许通过循环的最大次数。

Simple Loops. The following set of tests can be applied to simple loops, where n is the maximum number of allowable passes through the loop.

  1. 完全跳过循环。

  2. Skip the loop entirely.

  3. 只有一次通过循环。

  4. Only one pass through the loop.

  5. 两次通过循环。

  6. Two passes through the loop.

  7. m通过m < n的循环。

  8. m passes through the loop where m < n.

  9. n − 1, n , n + 1 通过循环。

  10. n − 1, n, n + 1 passes through the loop.

嵌套循环。如果我们将简单循环的测试方法扩展到嵌套循环,则可能的测试数量将随着嵌套级别的增加呈几何级数增长。这将导致测试数量不切实际。Beizer [Bei90]提出了一种有助于减少测试数量的方法:

Nested Loops. If we were to extend the test approach for simple loops to nested loops, the number of possible tests would grow geometrically as the level of nesting increases. This would result in an impractical number of tests. Beizer [Bei90] suggests an approach that will help to reduce the number of tests:

  1. 从最里面的循环开始。将所有其他循环设置为最小值。

  2. Start at the innermost loop. Set all other loops to minimum values.

  3. 对最内层循环进行简单的循环测试,同时将外层循环保持在其最小迭代参数(例如,循环计数器)值。为超出范围或排除的值添加其他测试。

  4. Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter (e.g., loop counter) values. Add other tests for out-of-range or excluded values.

  5. 向外工作,对下一个循环进行测试,但将所有其他外循环保持为最小值,并将其他嵌套循环保持为“典型”值。

  6. Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to “typical” values.

  7. 继续,直到所有循环都经过测试。

  8. Continue until all loops have been tested.

第388页

Page 388

19.5 黑盒测试

19.5 Black-Box Testing

黑盒测试,也称为行为测试功能测试,重点关注软件的功能需求。也就是说,黑盒测试技术使您能够导出能够充分执行程序的所有功能要求的输入条件集。黑盒测试不能替代白盒技术。相反,它是一种补充方法,可能会发现与白盒方法不同类别的错误。

Black-box testing, also called behavioral testing or functional testing, focuses on the functional requirements of the software. That is, black-box testing techniques enable you to derive sets of input conditions that will fully exercise all functional requirements for a program. Black-box testing is not an alternative to white-box techniques. Rather, it is a complementary approach that is likely to uncover a different class of errors than white-box methods.

黑盒测试试图发现以下类别的错误:(1) 不正确或缺失的功能,(2) 接口错误,(3) 数据结构或外部数据库访问错误,(4) 行为或性能错误,以及 (5) ) 初始化和终止错误。

Black-box testing attempts to find errors in the following categories: (1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external database access, (4) behavior or performance errors, and (5) initialization and termination errors.

与在测试过程早期执行的白盒测试不同,黑盒测试往往在测试的后期阶段应用。由于黑盒测试故意忽略控制结构,因此注意力集中在信息领域。测试旨在回答以下问题:

Unlike white-box testing, which is performed early in the testing process, black-box testing tends to be applied during later stages of testing. Because black-box testing purposely disregards control structure, attention is focused on the information domain. Tests are designed to answer the following questions:

  • 如何测试功能有效性?

  • How is functional validity tested?

  • 如何测试系统行为和性能?

  • How are system behavior and performance tested?

  • 哪些类型的输入可以构成良好的测试用例?

  • What classes of input will make good test cases?

  • 系统是否对某些输入值特别敏感?

  • Is the system particularly sensitive to certain input values?

  • 数据类的边界如何隔离?

  • How are the boundaries of a data class isolated?

  • 系统可以承受哪些数据速率和数据量?

  • What data rates and data volume can the system tolerate?

  • 特定的数据组合会对系统运行产生什么影响?

  • What effect will specific combinations of data have on system operation?

通过应用黑盒技术,您可以派生一组满足以下条件的测试用例 [Mye79]:通过大于 1 的计数减少必须设计的附加测试用例数量以实现合理的测试用例测试和测试用例告诉您有关错误类别是否存在的信息,而不是仅与当前特定测试相关的错误。

By applying black-box techniques, you derive a set of test cases that satisfy the following criteria [Mye79]: test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing, and test cases that tell you something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

19.5.1 接口测试

19.5.1 Interface Testing

接口测试用于检查程序组件是否接受以正确的顺序和数据类型传递给它的信息,并以正确的顺序和数据格式返回信息[Jan16]。接口测试通常被认为是集成测试的一部分。由于大多数组件都不是独立的程序,因此确保组件集成到不断发展的程序中时不会破坏构建非常重要。这就是使用存根和驱动程序(第 19.2.1 节)对于组件测试人员变得重要的地方。

Interface testing is used to check that the program component accepts information passed to it in the proper order and data types and returns information in proper order and data format [Jan16]. Interface testing is often considered part of integration testing. Because most components are not stand-alone programs, it is important to make sure that when the component is integrated into the evolving program it will not break the build. This is where the use stubs and drivers (Section 19.2.1) become important to component testers.

存根和驱动程序有时会包含要传递给组件或由组件访问的测试用例。在其他情况下,可能需要在组件内部插入调试代码以检查传递的数据是否正确接收(第 19.3 节)。在其他情况下,测试框架应该包含代码来检查从组件返回的数据是否被正确接收。一些敏捷开发人员更喜欢使用不断发展的程序的生产版本的副本进行接口测试,并添加一些调试代码。第389页

Stubs and drivers sometimes incorporate test cases to be passed to the component or accessed by the component. In other cases, debugging code may need to be inserted inside the component to check that data passed was received correctly (Section 19.3). In still other cases, the testing framework should contain code to check that data returned from the component is received correctly. Some agile developers prefer to do interface testing using a copy of the production version of the evolving program with some of this debugging code added.Page 389

19.5.2 等价划分

19.5.2 Equivalence Partitioning

等价划分是一种黑盒测试方法,它将程序的输入域划分为可以派生测试用例的数据类。理想的测试用例可以单独发现一类错误(例如,所有字符数据的错误处理),否则可能需要在观察到一般错误之前执行许多测试用例。

Equivalence partitioning is a black-box testing method that divides the input domain of a program into classes of data from which test cases can be derived. An ideal test case single-handedly uncovers a class of errors (e.g., incorrect processing of all character data) that might otherwise require many test cases to be executed before the general error is observed.

等价划分的测试用例设计基于对输入条件的等价类的评估。使用上一节中介绍的概念,如果一组对象可以通过对称、传递和自反的关系链接起来,则存在等价类[Bei95]。等价类表示输入条件的一组有效或无效状态。通常,输入条件是特定数值、值范围、一组相关值或布尔条件。等价类可以根据以下准则定义:

Test-case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition. Using concepts introduced in the preceding section, if a set of objects can be linked by relationships that are symmetric, transitive, and reflexive, an equivalence class is present [Bei95]. An equivalence class represents a set of valid or invalid states for input conditions. Typically, an input condition is either a specific numeric value, a range of values, a set of related values, or a Boolean condition. Equivalence classes may be defined according to the following guidelines:

  1. 如果输入条件指定一个范围,则定义一个有效等价类和两个无效等价类。

  2. If an input condition specifies a range, one valid and two invalid equivalence classes are defined.

  3. 如果输入条件需要特定值,则定义一个有效等价类和两个无效等价类。

  4. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.

  5. 如果输入条件指定集合的​​成员,则定义一个有效的等价类和一个无效的等价类。

  6. If an input condition specifies a member of a set, one valid and one invalid equivalence class are defined.

  7. 如果输入条件是布尔值,则定义一种有效类别和一种无效类别。

  8. If an input condition is Boolean, one valid and one invalid class are defined.

通过应用等价类的推导准则,可以开发和执行每个输入域数据项的测试用例。选择测试用例以便一次执行最大数量的等价类属性。

By applying the guidelines for the derivation of equivalence classes, test cases for each input domain data item can be developed and executed. Test cases are selected so that the largest number of attributes of an equivalence class are exercised at once.

19.5.3 边界值分析

19.5.3 Boundary Value Analysis

更多的错误发生在输入域的边界而不是“中心”。正是由于这个原因,边界值分析(BVA)被开发为一种测试技术。边界值分析导致选择执行边界值的测试用例。

A greater number of errors occurs at the boundaries of the input domain rather than in the “center.” It is for this reason that boundary value analysis (BVA) has been developed as a testing technique. Boundary value analysis leads to a selection of test cases that exercise bounding values.

边界值分析是一种测试用例设计技术,可补充等价划分。BVA 不是选择等价类的任何元素,而是导致在类的“边缘”选择测试用例。BVA 不只关注输入条件,而是从输出域派生测试用例 [Mye79]。

Boundary value analysis is a test-case design technique that complements equivalence partitioning. Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the “edges” of the class. Rather than focusing solely on input conditions, BVA derives test cases from the output domain as well [Mye79].

BVA 准则在许多方面与为等价划分提供的准则相似:

Guidelines for BVA are similar in many respects to those provided for equivalence partitioning:

  1. 如果输入条件指定由值ab 限定的范围,则测试用例应设计为值ab以及a和b的正上方和正下方

  2. If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b.

  3. 如果输入条件指定了多个值,则应开发测试用例来执行最小和最大数字。还测试了刚好高于和低于最小值和最大值的值。

  4. If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested.

  5. 将准则 1 和 2 应用到输出条件。例如,假设需要温度与压力表作为工程分析程序的输出。测试用例应设计为创建一个输出报告,该报告产生最大(和最小)允许的表条目数。第390页

  6. Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature versus pressure table is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries.Page 390

  7. 如果内部程序数据结构有规定的边界(例如,表的定义限制为 100 个条目),请务必设计一个测试用例来在其边界处执行数据结构。

  8. If internal program data structures have prescribed boundaries (e.g., a table has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.

大多数软件工程师都会在某种程度上直观地执行 BVA。通过应用这些准则,边界测试将更加完整,从而提高错误检测的可能性。

Most software engineers intuitively perform BVA to some degree. By applying these guidelines, boundary testing will be more complete, thereby having a higher likelihood for error detection.

19.6 面向对象测试

19.6 Object-Oriented Testing

当考虑面向对象的软件时,单元的概念发生了变化。封装驱动类和对象的定义。这意味着每个类和类的每个实例都封装了属性(数据)以及操纵这些数据的操作。封装类通常是单元测试的焦点。然而,类内的操作(​​方法)是最小的可测试单元。由于一个类可以包含许多不同的操作,并且特定操作可能作为许多不同类的一部分存在,因此应用于单元测试的策略必须改变。

When object-oriented software is considered, the concept of the unit changes. Encapsulation drives the definition of classes and objects. This means that each class and each instance of a class packages attributes (data) and the operations that manipulate these data. An encapsulated class is usually the focus of unit testing. However, operations (methods) within the class are the smallest testable units. Because a class can contain a number of different operations, and a particular operation may exist as part of a number of different classes, the tactics applied to unit testing must change.

您不能再单独测试单个操作(单元测试的传统视图),而是将其作为类的一部分进行测试。为了说明这一点,请考虑一个类层次结构,其中为超类定义了操作 X,并由许多子类继承。每个子类都使用操作 X,但它是在为子类定义的私有属性和操作的上下文中应用的。由于使用操作 X 的上下文有细微的差异,因此有必要在每个子类的上下文中测试操作 X。这意味着以独立方式测试操作 X(传统的单元测试方法)在面向对象的上下文中通常是无效的。

You can no longer test a single operation in isolation (the conventional view of unit testing) but rather as part of a class. To illustrate, consider a class hierarchy in which an operation X is defined for the superclass and is inherited by a number of subclasses. Each subclass uses operation X, but it is applied within the context of the private attributes and operations that have been defined for the subclass. Because the context in which operation X is used varies in subtle ways, it is necessary to test operation X in the context of each of the subclasses. This means that testing operation X in a stand-alone fashion (the conventional unit-testing approach) is usually ineffective in the object-oriented context.

19.6.1 类测试

19.6.1 Class Testing

面向对象(OO)软件的类测试相当于传统软件的单元测试。与传统软件的单元测试倾向于关注模块的算法细节和流经模块接口的数据不同,面向对象软件的类测试是由类封装的操作和类的状态行为驱动的。

Class testing for object-oriented (OO) software is the equivalent of unit testing for conventional software. Unlike unit testing of conventional software, which tends to focus on the algorithmic detail of a module and the data that flow across the module interface, class testing for OO software is driven by the operations encapsulated by the class and the state behavior of the class.

为了提供这些方法的简要说明,请考虑一个银行应用程序,其中Account类具有以下操作:open()、setup()、deposit()、withdraw()、balance()、summary()、creditLimit()、close() [Kir94]。这些操作中的每一个都可以应用于帐户,但是问题的性质暗示了某些限制(例如,必须在应用其他操作之前打开帐户并在所有操作完成后关闭帐户)。即使有这些限制,操作仍有许多排列。Account实例的最小行为生命历史包括以下操作:

To provide brief illustrations of these methods, consider a banking application in which an Account class has the following operations: open(), setup(), deposit(), withdraw(), balance(), summarize(), creditLimit(), and close() [Kir94]. Each of these operations may be applied for Account, but certain constraints (e.g., the account must be opened before other operations can be applied and closed after all operations are completed) are implied by the nature of the problem. Even with these constraints, there are many permutations of the operations. The minimum behavioral life history of an instance of Account includes the following operations:

开通•设置•充值•提现•关闭

open•setup•deposit•withdraw•close

第391页这代表帐户的最小测试序列。然而,在此序列中可能会发生多种其他行为:

Page 391This represents the minimum test sequence for account. However, a wide variety of other behaviors may occur within this sequence:

开仓•设置•存款•[存款|取款|余额|汇总|信用限额] n •取款•关闭

open•setup•deposit•[deposit|withdraw|balance|summarize|creditLimit]n•withdraw•close

可以随机生成多种不同的操作序列。例如:

A variety of different operation sequences can be generated randomly. For example:

测试用例 r 1

Test case r1:

开仓·设置·充值·充值·余额·汇总·提现·关闭

open•setup•deposit•deposit•balance•summarize•withdraw•close

测试用例 r 2

Test case r2:

开仓•设置•存款•提款•存款•余额•信用限额•提款•关闭

open•setup•deposit•withdraw•deposit•balance•creditLimit•withdraw•close

进行这些和其他随机顺序测试是为了练习不同类实例的生活史。使用测试等价划分(第 19.5.2 节)可以减少所需测试用例的数量。

These and other random order tests are conducted to exercise different class instance life histories. Use of test equivalence partitioning (Section 19.5.2) can reduce the number of test cases required.

19.6.2 行为测试

19.6.2 Behavioral Testing

第392页第 8 章讨论了使用状态图作为表示类动态行为的模型。类的状态图可用于帮助派生一系列测试,这些测试将练习该类(以及与其协作的那些类)的动态行为。图 19.7 [Kir94] 展示了前面讨论的Account类的状态图。参考该图,初始转换经过空帐户设置帐户状态。类实例的大部分行为发生在工作帐户状态下。最终提款和帐户关闭会导致帐户类分别转换到非工作帐户死帐户状态。

Page 392The use of the state diagram as a model that represents the dynamic behavior of a class is discussed in Chapter 8. The state diagram for a class can be used to help derive a sequence of tests that will exercise the dynamic behavior of the class (and those classes that collaborate with it). Figure 19.7 [Kir94] illustrates a state diagram for the Account class discussed earlier. Referring to the figure, initial transitions move through the empty acct and setup acct states. The majority of all behavior for instances of the class occurs while in the working acct state. A final withdrawal and account closure cause the account class to make transitions to the nonworking acct and dead acct states, respectively.

图19.7 Account 类的状态

Figure 19.7 State diagram for the Account class

来源:Kirani、Shekhar 和 Tsai,WT,“面向对象程序的规范和验证”,技术报告 TR 94-64,明尼苏达大学,1994 年 12 月,79。

Source: Kirani, Shekhar and Tsai, W. T., “Specification and Verification of Object-Oriented Programs,” Technical Report TR 94-64, University of Minnesota, December 1994, 79.

所设计的测试应该覆盖每个状态。也就是说,操作序列应导致Account类转换所有允许的状态:

The tests to be designed should achieve coverage of every state. That is, the operation sequences should cause the Account class to transition through all allowable states:

测试用例 s 1 打开·setupAccnt·存款(初始)·取款(最终)·关闭

Test case s1: open•setupAccnt•deposit (initial)•withdraw (final)•close

将额外的测试序列添加到最小序列,

Adding additional test sequences to the minimum sequence,

测试用例 s 2 打开·setupAccnt·存款(初始)·存款·余额·贷记·取款(最终)·关闭

Test case s2: open•setupAccnt•deposit(initial)•deposit•balance•credit• withdraw (final)•close

测试用例 s 3 打开•setupAccnt•存款(初始)•存款•取款•accntInfo•取款(最终)•关闭

Test case s3: open•setupAccnt•deposit(initial)•deposit•withdraw•accntInfo• withdraw (final)•close

第393页还可以派生出更多测试用例,以确保该类的所有行为都得到充分运用。在类行为导致与一个或多个类协作的情况下,可以使用多个状态图来跟踪系统的行为流。

Page 393Still more test cases could be derived to ensure that all behaviors for the class have been adequately exercised. In situations in which the class behavior results in a collaboration with one or more classes, multiple state diagrams are used to track the behavioral flow of the system.

状态模型可以以“广度优先”[McG94]的方式遍历。在这种情况下,广度优先意味着测试用例执行单个转换,并且当要测试新转换时,仅使用先前测试的转换。

The state model can be traversed in a “breadth-first” [McG94] manner. In this context, breadth-first implies that a test case exercises a single transition and that when a new transition is to be tested, only previously tested transitions are used.

考虑一个属于银行系统一部分的CreditCard对象。CreditCard的初始状态未定义(即未提供信用卡号)在销售过程中读取信用卡后,该对象就会呈现出定义的状态;也就是说,定义了属性card numberexpiration date以及银行特定的标识符。发送授权时信用卡即被提交,收到授权时信用卡即被批准。信用卡从一种状态到另一种状态的转换可以通过派生导致转换发生的测试用例来测试。此类测试的广度优先方法不会在执行未定义和已定义之前提交如果这样做,它将利用先前未测试过的转换,因此将违反广度优先标准。

Consider a CreditCard object that is part of the banking system. The initial state of CreditCard is undefined (i.e., no credit card number has been provided). Upon reading the credit card during a sale, the object takes on a defined state; that is, the attributes card number and expiration date, along with bank-specific identifiers, are defined. The credit card is submitted when it is sent for authorization, and it is approved when authorization is received. The transition of CreditCard from one state to another can be tested by deriving test cases that cause the transition to occur. A breadth-first approach to this type of testing would not exercise submitted before it exercised undefined and defined. If it did, it would make use of transitions that had not been previously tested and would therefore violate the breadth-first criterion.

19.7 总结

19.7 Summary

软件测试在软件过程中的技术工作中所占的比例最大。无论您构建哪种类型的软件,系统测试计划、执行和控制的策略都从考虑软件的小元素开始,然后向外延伸到整个程序。

Software testing accounts for the largest percentage of technical effort in the software process. Regardless of the type of software you build, a strategy for systematic test planning, execution, and control begins by considering small elements of the software and moves outward toward the program as a whole.

软件测试的目的是发现错误。对于传统软件来说,这个目标是通过一系列测试步骤来实现的。单元和集成测试(第 20 章中讨论)集中于组件的功能验证以及将组件合并到软件架构中。测试面向对象软件的策略从在类中执行操作的测试开始,然后转向基于线程的集成测试(在第20.4.1 节中讨论)。线程是响应输入或事件的类集。

The objective of software testing is to uncover errors. For conventional software, this objective is achieved through a series of test steps. Unit and integration tests (discussed in Chapter 20) concentrate on functional verification of a component and incorporation of components into the software architecture. The strategy for testing object-oriented software begins with tests that exercise the operations within a class and then moves to thread-based testing for integration (discussed in Section 20.4.1). Threads are sets of classes that respond to an input or event.

测试用例应该可追溯到软件需求。每个测试步骤都是通过一系列有助于测试用例设计的系统测试技术来完成的。通过每个测试步骤,软件考虑的抽象级别都会扩大。测试用例设计的主要目标是导出一组最有可能发现软件错误的测试。为了实现这一目标,使用了两种不同类别的测试用例设计技术:白盒测试和黑盒测试。

Test cases should be traceable to software requirements. Each test step is accomplished through a series of systematic test techniques that assist in the design of test cases. With each testing step, the level of abstraction with which software is considered is broadened. The primary objective for test-case design is to derive a set of tests that have the highest likelihood for uncovering errors in software. To accomplish this objective, two different categories of test-case design techniques are used: white-box testing and black-box testing.

白盒测试重点关注程序控制结构。导出测试用例是为了确保程序中的所有语句在测试过程中至少执行一次,并且所有逻辑条件都已得到执行。基本路径测试是一种白盒技术,利用程序图(或图矩阵)来派生一组线性独立的测试,以确保覆盖率。条件和数据流测试进一步练习程序逻辑,循环测试通过提供练习不同复杂程度循环的过程来补充其他白盒技术。

White-box tests focus on the program control structure. Test cases are derived to ensure that all statements in the program have been executed at least once during testing and that all logical conditions have been exercised. Basis path testing, a white-box technique, makes use of program graphs (or graph matrices) to derive the set of linearly independent tests that will ensure coverage. Condition and data flow testing further exercise program logic, and loop testing complements other white-box techniques by providing a procedure for exercising loops of varying degrees of complexity.

第394页黑盒测试旨在验证功能需求,而不考虑程序的内部工作原理。黑盒测试技术侧重于软件的信息域,通过以提供全面测试覆盖的方式划分程序的输入和输出域来派生测试用例。等价划分将输入域划分为可能执行特定软件功能的数据类。边界值分析探测程序在可接受的限度内处理数据的能力。

Page 394Black-box tests are designed to validate functional requirements without regard to the internal workings of a program. Black-box testing techniques focus on the information domain of the software, deriving test cases by partitioning the input and output domain of a program in a manner that provides thorough test coverage. Equivalence partitioning divides the input domain into classes of data that are likely to exercise a specific software function. Boundary value analysis probes the program’s ability to handle data at the limits of acceptability.

与测试(系统的、有计划的活动)不同,调试可以被视为一门艺术。从问题的症状指示开始,调试活动必须追踪错误的原因。测试有时可以帮助找到错误的根本原因。但通常,最有价值的资源是软件工程人员其他成员的建议。

Unlike testing (a systematic, planned activity), debugging can be viewed as an art. Beginning with a symptomatic indication of a problem, the debugging activity must track down the cause of an error. Testing can sometimes help find the root cause of the error. But often, the most valuable resource is the counsel of other members of the software engineering staff.

问题与思考点

Problems and Points to Ponder

19.1。用你自己的话描述验证和确认之间的区别。两者都使用测试用例设计方法和测试策略吗?

19.1. Using your own words, describe the difference between verification and validation. Do both make use of test-case design methods and testing strategies?

19.2。列出一些可能与创建独立测试组相关的问题。ITG 和 SQA 小组是由同一个人组成吗?

19.2. List some problems that might be associated with the creation of an independent test group. Are an ITG and an SQA group made up of the same people?

19.3。为什么高度耦合的模块很难进行单元测试?

19.3. Why is a highly coupled module difficult to unit test?

19.4。在所有情况下单元测试都是可能的,甚至是可取的吗?提供例子来证明你的答案。

19.4. Is unit testing possible or even desirable in all circumstances? Provide examples to justify your answer.

19.5。您能想到第 19.1.1 节中未讨论的任何其他测试目标吗?

19.5. Can you think of any additional testing objectives that are not discussed in Section 19.1.1?

19.6。选择您最近设计和实现的软件组件。设计一组测试用例,确保所有语句都已使用基本路径测试执行。

19.6. Select a software component that you have designed and implemented recently. Design a set of test cases that will ensure that all statements have been executed using basis path testing.

19.7。Myers [Mye79] 使用以下程序作为自我评估,以评估您指定充分测试的能力:一个程序读取三个整数值。这三个值被解释为表示三角形边的长度。该程序打印一条消息,说明三角形是不等边三角形、等腰三角形还是等边三角形。开发一组您认为可以充分测试该程序的测试用例。

19.7. Myers [Mye79] uses the following program as a self-assessment for your ability to specify adequate testing: A program reads three integer values. The three values are interpreted as representing the lengths of the sides of a triangle. The program prints a message that states whether the triangle is scalene, isosceles, or equilateral. Develop a set of test cases that you feel will adequately test this program.

19.8。设计并实现问题 19.7中指定的程序(在适当的情况下进行错误处理)。导出程序的流程图并应用基本路径测试来开发测试用例,以保证程序中的所有语句都经过测试。执行案例并展示您的结果。

19.8. Design and implement the program (with error handling where appropriate) specified in Problem 19.7. Derive a flow graph for the program and apply basis path testing to develop test cases that will guarantee that all statements in the program have been tested. Execute the cases and show your results.

19.9。至少给出三个例子,其中黑盒测试可能给人“一切正常”的印象,而白盒测试可能会发现错误。至少给出三个例子,其中白盒测试可能给人“一切正常”的印象,而黑盒测试可能会发现错误。

19.9. Give at least three examples in which black-box testing might give the impression that “everything’s OK,” while white-box tests might uncover an error. Give at least three examples in which white-box testing might give the impression that “everything’s OK,” while black-box tests might uncover an error.

19.10。用您自己的话描述为什么类是 OO 系统中测试的最小合理单元。

19.10. In your own words, describe why the class is the smallest reasonable unit for testing within an OO system.

1应该指出的是,对于什么类型的测试构成“验证”存在很大的分歧。有些人认为所有测试都是验证,验证是在需求被审查和批准时进行的,然后由用户在系统运行时进行的。其他人将单元和集成测试(第 19 章和第 20 章)视为验证,将高阶测试(第 21 章)视为验证。

1 It should be noted that there is a strong divergence of opinion about what types of testing constitute “validation.” Some people believe that all testing is verification and that validation is conducted when requirements are reviewed and approved, and later, by the user when the system is operational. Other people view unit and integration testing (Chapters 19 and 20) as verification and higher-order testing (Chapter 21) as validation.

2 Gilb [Gil95] 建议软件团队“学会在快速周期(项目工作量的 2%)中测试对客户有用的、至少是现场‘可试用’的功能增量和/或质量改进。” 这些快速循环测试生成的反馈可用于控制质量水平和相应的测试策略。

2 Gilb [Gil95] recommends that a software team “learn to test in rapid cycles (2 percent of project effort) of customer-useful, at least field ‘trialable,’ increments of functionality and/or quality improvement.” The feedback generated from these rapid cycle tests can be used to control quality levels and the corresponding test strategies.

3有时,在创建滥用案例的过程中会描述反需求,这些案例从恶意用户的角度描述用户故事,并且是威胁分析的一部分(在第 18 章中讨论)。

3 Anti-requirements are sometimes described during the creation of abuse cases that describe a user story from the perspective of a malicious user and are part of threat analysis (discussed in Chapter 18).

4实际上,基本路径法可以在不使用流程图的情况下进行。然而,它们可以作为理解控制流和说明方法的有用符号。

4 In actuality, the basis path method can be conducted without the use of flow graphs. However, they serve as a useful notation for understanding control flow and illustrating the approach.

章节

chapter

第395页

Page 395

20软件测试——集成级别

20 Software Testing—Integration Level

单个开发人员可以在不涉及其他团队成员的情况下测试软件组件。对于集成测试来说,情况并非如此,其中组件必​​须与其他团队成员开发的组件正确交互。集成测试暴露了没有凝聚成一个团队的软件开发团队的许多弱点。集成测试给软件工程师带来了一个有趣的困境,因为他们本质上是有建设性的人。事实上,所有的测试都要求开发人员放弃对刚开发的软件“正确性”的先入为主的观念,转而努力设计测试用例来“破坏”软件。这意味着团队成员需要能够接受其他团队成员的建议,即他们的代码在作为最新软件增量的一部分进行测试时表现不正常。

A single developer may be able to test software components without involving other team members. This is not true for integration testing where a component must interact properly with components developed by other team members. Integration testing exposes many weaknesses of software development groups who have not gelled as a team. Integration testing presents an interesting dilemma for software engineers, who by their nature are constructive people. In fact, all testing requires that developers discard preconceived notions of the “correctness” of software just developed and instead work hard to design test cases to “break” the software. This means that team members need to be able to accept suggestions from other team members that their code is not behaving properly when it is tested as part of the latest software increment.

第396页Beizer [Bei90] 描述了所有测试人员都会面临的“软件神话”。他写道:“有一个神话认为,如果我们真的擅长编程,就不会有任何错误可以捕获。。。神话说,存在错误是因为我们不擅长做事;如果我们做得不好,我们就应该感到内疚。”

Page 396Beizer [Bei90] describes a “software myth” that all testers face. He writes: “There’s a myth that if we were really good at programming, there would be no bugs to catch . . . There are bugs, the myth says, because we are bad at what we do; and if we are bad at it, we should feel guilty about it.”

测试应该让人感到内疚吗?测试真的具有破坏性吗?这些问题的答案是:不!

Should testing instill guilt? Is testing really destructive? The answer to these questions is, No!

在本书的开头,我们强调了这样一个事实:软件只是更大的基于计算机的系统的一个元素。最终,软件与其他系统元素(例如硬件、人员、信息)合并,并进行系统测试(一系列系统集成和验证测试)。这些测试不属于软件过程的范围,并且不仅仅由软件工程师进行。然而,在软件设计和测试过程中采取的步骤可以大大提高在大型系统中成功集成软件的可能性。

At the beginning of this book, we stressed the fact that software is only one element of a larger computer-based system. Ultimately, software is incorporated with other system elements (e.g., hardware, people, information), and systems testing (a series of system integration and validation tests) is conducted. These tests fall outside the scope of the software process and are not conducted solely by software engineers. However, steps taken during software design and testing can greatly improve the probability of successful software integration in the larger system.

在本章中,我们讨论适用于大多数软件应用程序的软件集成测试策略技术。第 21 章讨论了专门的软件测试策略。

In this chapter, we discuss techniques for software integration testing strategies applicable to most software applications. Specialized software testing strategies are discussed in Chapter 21.

20.1 软件测试基础知识

20.1 Software Testing Fundamentals

测试的目的是发现错误,好的测试是发现错误的可能性很高的测试。Kaner、Falk 和 Nguyen [Kan93] 建议“好”测试具有以下属性:

The goal of testing is to find errors, and a good test is one that has a high probability of finding an error. Kaner, Falk, and Nguyen [Kan93] suggest the following attributes of a “good” test:

好的测试很有可能发现错误。为了实现这一目标,测试人员必须了解软件并尝试在脑海中想象出软件可能会如何失败。

A good test has a high probability of finding an error. To achieve this goal, the tester must understand the software and attempt to develop a mental picture of how the software might fail.

好的测试并不多余。测试时间和资源都是有限的。进行与另一项测试具有相同目的的测试是没有意义的。每个测试都应该有不同的目的(即使略有不同)。

A good test is not redundant. Testing time and resources are limited. There is no point in conducting a test that has the same purpose as another test. Every test should have a different purpose (even if it is subtly different).

一个好的测试应该是“同类最佳” [Kan93]。在一组具有相似意图的测试中,时间和资源限制可能会决定仅执行那些最有可能发现整类错误的测试。

A good test should be “best of breed” [Kan93]. In a group of tests that have a similar intent, time and resource limitations may dictate the execution of only those tests that have the highest likelihood of uncovering a whole class of errors.

一个好的测试既不能太简单也不能太复杂。尽管有时可以将一系列测试组合到一个测试用例中,但与此方法相关的可能的副作用可能会掩盖错误。一般来说,每个测试应该单独执行。

A good test should be neither too simple nor too complex. Although it is sometimes possible to combine a series of tests into one test case, the possible side effects associated with this approach may mask errors. In general, each test should be executed separately.

任何工程产品(以及大多数其他产品)都可以通过以下两种方式之一进行测试:(1)了解产品设计要执行的指定功能,可以进行测试以证明每个功能都可以完全运行搜索每个函数中的错误。(2)了解产品的内部工作情况,可以进行测试以确保“所有齿轮都啮合”,即内部操作按规范进行,所有内部部件都得到充分的锻炼。第一种测试方法采用外部视图进行测试,称为黑盒测试。第二个需要测试的内部视图,称为白盒测试1两者在集成测试中都很有用 [Jan16]。第397页

Any engineered product (and most other things) can be tested in one of two ways: (1) Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrate each function is fully operational while at the same time searching for errors in each function. (2) Knowing the internal workings of a product, tests can be conducted to ensure that “all gears mesh,” that is, internal operations are performed according to specifications and all internal components have been adequately exercised. The first test approach takes an external view of testing and is called black-box testing. The second requires an internal view of testing and is termed white-box testing.1 Both are useful in integration testing [Jan16].Page 397

20.1.1 黑盒测试

20.1.1 Black-Box Testing

黑盒测试指的是通过测试组件与其他组件和其他系统的接口来进行的集成测试。它检查系统的一些基本方面,很少考虑软件的内部逻辑结构。相反,重点是确保当先决条件指定的输入数据和软件上下文正确并且按照后置条件指定的方式运行时,组件在较大的软件构建中正确执行。当然,重要的是要确保组件在不满足先决条件时正确运行(例如,它可以处理错误的输入而不崩溃)。

Black-box testing alludes to integration testing that is conducted by exercising the component interfaces with other components and with other systems. It examines some fundamental aspect of a system with little regard for the internal logical structure of the software. Instead, the focus is on ensuring the component executes correctly in the larger software build when the input data and software context specified by its preconditions is correct and behaves in the ways specified by its postconditions. It is of course important to make sure that the component behaves correctly when its preconditions are not satisfied (e.g., it can handle bad inputs without crashing).

黑盒测试基于用户故事(第 7 章)中指定的要求。一旦定义了组件接口,测试用例作者就不需要等待编写组件实现代码。可能需要编写多个协作组件来实现单个用户故事定义的功能。验证测试(第 20.5 节)通常根据最终用户可见的输入操作和可观察的输出行为来定义黑盒测试用例,而不了解组件本身是如何实现的。

Black-box testing is based on the requirements specified in user stories (Chapter 7). Test-case authors do not need to wait for the component implementation code to be written once the component interface is defined. Several cooperating components may need to be written to implement the functionality defined by a single user story. Validation testing (Section 20.5) often defines black-box test cases in terms of the end-user visible input actions and observable output behaviors, without any knowledge of how the components themselves were implemented.

20.1.2 白盒测试

20.1.2 White-Box Testing

白盒测试,有时称为玻璃盒测试结构测试,是一种集成测试哲学,它使用作为组件级设计的一部分描述的控制结构的实现知识来派生测试用例。软件的白盒测试基于对程序实现细节和数据结构实现细节的仔细检查。只有在组件级设计(或源代码)存在之后才能设计白盒测试。程序的逻辑细节必须可用。软件的逻辑路径以及组件之间的协作是白盒集成测试的重点。

White-box testing, sometimes called glass-box testing or structural testing, is an integration testing philosophy that uses implementation knowledge of the control structures described as part of component-level design to derive test cases. White-box testing of software is predicated on close examination of procedural implementation details and data structure implementation details. White-box tests can be designed only after component-level design (or source code) exists. The logical details of the program must be available. Logical paths through the software and collaborations between components are the focus of white-box integration testing.

乍一看,非常彻底的白盒测试似乎会导致“100%正确的程序”。我们需要做的就是定义所有的逻辑路径,开发测试用例来演练它们,并评估结果,即生成测试用例来详尽地演练程序逻辑。不幸的是,详尽的测试会带来某些后勤问题。即使对于小程序,可能的逻辑路径的数量也可能非常大。然而,白盒测试不应因为不切实际而被忽视。一旦发生组件集成,测试人员应该选择合理数量的重要逻辑路径来进行测试。组件集成后还应测试重要数据结构的有效性。

At first glance it would seem that very thorough white-box testing would lead to “100 percent correct programs.” All we need do is define all logical paths, develop test cases to exercise them, and evaluate results, that is, generate test cases to exercise program logic exhaustively. Unfortunately, exhaustive testing presents certain logistical problems. For even small programs, the number of possible logical paths can be very large. White-box testing should not, however, be dismissed as impractical. Testers should select a reasonable number of important logical paths to exercise once component integration occurs. Important data structures should also be tested for validity after component integration.

第398页

Page 398

20.2 集成测试

20.2 Integration Testing

一旦所有模块都经过单元测试,软件世界的新手可能会问一个看似合理的问题:“如果它们都单独工作,为什么你怀疑当我们将它们放在一起时它们是否会工作?” 当然,问题在于“将它们组合在一起”——接口。数据可能会通过接口丢失;一个组件可能会对另一个组件产生无意的不利影响;子功能组合后可能不会产生所需的主要功能;个人可接受的不精确性可能会被放大到不可接受的水平;全局数据结构可能会带来问题。可悲的是,这个名单还在不断增加。

A neophyte in the software world might ask a seemingly legitimate question once all modules have been unit-tested: “If they all work individually, why do you doubt that they’ll work when we put them together?” The problem, of course, is “putting them together”—interfacing. Data can be lost across an interface; one component can have an inadvertent, adverse effect on another; subfunctions, when combined, may not produce the desired major function; individually acceptable imprecision may be magnified to unacceptable levels; and global data structures can present problems. Sadly, the list goes on and on.

集成测试是一种系统技术,用于构建软件架构,同时进行测试以发现与接口相关的错误。目标是采用经过单元测试的组件并构建由设计决定的程序结构。

Integration testing is a systematic technique for constructing the software architecture while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit-tested components and build a program structure that has been dictated by design.

人们常常倾向于尝试非增量集成,即使用“大爆炸”方法构建程序。在大爆炸方法中,所有组件都预先组合在一起,并且整个程序作为一个整体进行测试。通常会导致混乱!虽然会遇到错误,但纠正起来很困难,因为整个程序的范围很广,导致原因的隔离变得很复杂。采用大爆炸式的集成方法是一种懒惰的策略,注定会失败。

There is often a tendency to attempt nonincremental integration, that is, to construct the program using a “big bang” approach. In the big bang approach, all components are combined in advance and the entire program is tested as a whole. Chaos usually results! Errors are encountered, but correction is difficult because isolation of causes is complicated by the vast expanse of the entire program. Taking the big bang approach to integration is a lazy strategy that is doomed to failure.

增量集成是大爆炸方法的对立面。该程序以小增量构建和测试,其中错误更容易隔离和纠正;接口更有可能经过完全测试;并且可以应用系统的测试方法。增量集成和边测试边测试是一种更具成本效益的策略。我们将在本章的其余部分讨论几种常见的增量集成测试策略。

Incremental integration is the antithesis of the big bang approach. The program is constructed and tested in small increments, where errors are easier to isolate and correct; interfaces are more likely to be tested completely; and a systematic test approach may be applied. Integrate incrementally and testing as you go is a more cost-effective strategy. We discuss several common incremental integration testing strategies in the remainder of this chapter.

20.2.1 自上而下的集成

20.2.1 Top-Down Integration

自上而下的集成测试是一种构建软件架构的增量方法。模块(在本书中也称为组件)通过控制层次结构向下进行集成,从主控制模块(主程序)开始。从属于(并且最终从属于)主控制模块的模块以深度优先或广度优先的方式合并到该结构中。

Top-down integration testing is an incremental approach to construction of the software architecture. Modules (also referred to as components in this book) are integrated by moving downward through the control hierarchy, beginning with the main control module (main program). Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.

参见图20.1深度优先集成将程序结构的主控制路径上的所有组件集成在一起。主要路径的选择在某种程度上是任意的,并且取决于特定于应用程序的特征(例如,实现一个用例所需的组件)。例如,选择左侧路径,分量M 1、M 2、M 5将首先被积分。接下来,M 8或(如果需要M 2的正常运行)M 6将被集成。然后,构建中央和右侧控制路径。广度优先集成将每个级别上直接从属的所有组件合并起来,在整个结构中水平移动。从图中可以看出,首先集成组件M 2、M 3和M 4 。接下来是下一个控制级别 M 5、M 6等等。集成过程分为五个步骤:

Referring to Figure 20.1, depth-first integration integrates all components on a major control path of the program structure. Selection of a major path is somewhat arbitrary and depends on application-specific characteristics (e.g., components needed to implement one use case). For example, selecting the left-hand path, components M1, M2, M5 would be integrated first. Next, M8 or (if necessary for proper functioning of M2) M6 would be integrated. Then, the central and right-hand control paths are built. Breadth-first integration incorporates all components directly subordinate at each level, moving across the structure horizontally. From the figure, components M2, M3, and M4 would be integrated first. The next control level, M5, M6, and so on, follows. The integration process is performed in a series of five steps:

图20.1 自上而下的集成

Figure 20.1 Top-down integration

  1. 主控模块用作测试驱动器,并且所有直接从属于主控模块的组件均被存根替代。

  2. The main control module is used as a test driver, and stubs are substituted for all components directly subordinate to the main control module.

  3. 第399页根据所选择的集成方法(即深度优先或广度优先),从属存根一次会被替换为实际组件。

  4. Page 399Depending on the integration approach selected (i.e., depth or breadth first), subordinate stubs are replaced one at a time with actual components.

  5. 测试是在集成每个组件时进行的。

  6. Tests are conducted as each component is integrated.

  7. 完成每组测试后,另一个存根将被替换为真实组件。

  8. On completion of each set of tests, another stub is replaced with the real component.

  9. 可以进行回归测试(本节稍后讨论)以确保没有引入新的错误。

  10. Regression testing (discussed later in this section) may be conducted to ensure that new errors have not been introduced.

该过程从步骤2继续进行,直到整个程序结构构建完成。

The process continues from step 2 until the entire program structure is built.

自上而下的集成策略在测试过程的早期验证主要控制或决策点。在“精心分解”的程序结构中,决策发生在层次结构的上层,因此首先遇到。如果确实存在重大控制问题,尽早识别至关重要。如果选择深度优先集成,则可以实现并演示软件的完整功能。尽早展示职能能力可以为所有利益相关者树立信心。

The top-down integration strategy verifies major control or decision points early in the test process. In a “well-factored” program structure, decision making occurs at upper levels in the hierarchy and is therefore encountered first. If major control problems do exist, early recognition is essential. If depth-first integration is selected, a complete function of the software may be implemented and demonstrated. Early demonstration of functional capability is a confidence builder for all stakeholders.

20.2.2 自下而上的集成

20.2.2 Bottom-Up Integration

自下而上的集成测试,顾名思义,是从原子模块(即程序结构中最低级别的组件)开始构建和测试。自下而上的集成消除了对复杂存根的需要。由于组件是自下而上集成的,因此从属于给定级别的组件提供的功能始终可用,并且消除了对存根的需要。自下而上的集成策略可以通过以下步骤实施:

Bottom-up integration testing, as its name implies, begins construction and testing with atomic modules (i.e., components at the lowest levels in the program structure). Bottom-up integration eliminates the need for complex stubs. Because components are integrated from the bottom up, the functionality provided by components subordinate to a given level is always available and the need for stubs is eliminated. A bottom-up integration strategy may be implemented with the following steps:

  1. 低级组件被组合成执行特定软件子功能的集群(有时称为构建)。

  2. Low-level components are combined into clusters (sometimes called builds) that perform a specific software subfunction.

  3. 编写驱动程序(用于测试的控制程序)来协调测试用例的输入和输出。

  4. A driver (a control program for testing) is written to coordinate test-case input and output.

  5. 集群已测试。

  6. The cluster is tested.

  7. 驱动程序被删除,簇被组合,在程序结构中向上移动。

  8. Drivers are removed and clusters are combined, moving upward in the program structure.

第 400 页积分遵循图 20.2所示的模式。组件组合起来形成集群 1、2 和 3。每个集群都使用驱动程序进行测试(显示为虚线块)。集群 1 和集群 2 中的组件从属于Ma。驱动器 D 1和 D 2被移除,并且集群直接连接到 M a类似地,在与模块M b集成之前移除集群3的驱动器D 3。Ma和 M b最终都将与组件 M c集成,依此类推。

Page 400Integration follows the pattern illustrated in Figure 20.2. Components are combined to form clusters 1, 2, and 3. Each of the clusters is tested using a driver (shown as a dashed block). Components in clusters 1 and 2 are subordinate to Ma. Drivers D1 and D2 are removed, and the clusters are interfaced directly to Ma. Similarly, driver D3 for cluster 3 is removed prior to integration with module Mb. Both Ma and Mb will ultimately be integrated with component Mc, and so forth.

图20.2 自下而上的集成

Figure 20.2 Bottom-up integration

随着集成度的提高,对单独测试驱动程序的需求也随之减少。事实上,如果将顶层两级程序结构自上而下地集成起来,就可以大大减少驱动程序的数量,并且大大简化集群的集成。

As integration moves upward, the need for separate test drivers lessens. In fact, if the top two levels of program structure are integrated top down, the number of drivers can be reduced substantially and integration of clusters is greatly simplified.

20.2.3 持续集成

20.2.3 Continuous Integration

持续集成是每天一次或多次将组件合并到不断发展的软件增量中的实践。这是遵循敏捷开发实践(例如 XP(第 3.5.1 节)或 DevOps(第 3.5.2 节))的团队的常见做法。如果团队试图始终将工作计划作为持续交付的一部分,那么集成测试必须快速有效地进行。有时很难使用持续集成工具来维护系统[Ste18]。维护和持续集成问题在第 22.4 节中有更详细的讨论。

Continuous integration is the practice of merging components into the evolving software increment once or more each day. This is a common practice for teams following agile development practices such as XP (Section 3.5.1) or DevOps (Section 3.5.2). Integration testing must take place quickly and efficiently if a team is attempting to always have a working program in place as part of continuous delivery. It is sometimes hard to maintain systems with the use of continuous integration tools [Ste18]. Maintenance and continuous integration issues are discussed in more detail in Section 22.4.

第401页冒烟测试是一种集成测试方法,当敏捷团队使用较短的增量构建时间开发产品软件时,可以使用该方法。冒烟测试可能被描述为滚动或持续集成策略。该软件每天都会进行重建(添加新组件)并进行冒烟测试。它被设计为时间紧迫的项目的节奏机制,允许软件团队频繁地评估项目。本质上,冒烟测试方法包括以下活动:

Page 401Smoke testing is an integration testing approach that can be used when product software is developed by an agile team using short increment build times. Smoke testing might be characterized as a rolling or continuous integration strategy. The software is rebuilt (with new components added) and smoke tested every day. It is designed as a pacing mechanism for time-critical projects, allowing the software team to assess the project on a frequent basis. In essence, the smoke-testing approach encompasses the following activities:

  1. 已转换为代码的软件组件被集成到构建中。构建包括实现一项或多项产品功能所需的所有数据文件、库、可重用模块和工程组件。

  2. Software components that have been translated into code are integrated into a build. A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or more product functions.

  3. 一系列测试旨在暴露导致构建无法正确执行其功能的错误。目的应该是发现最有可能导致软件项目落后于计划的“令人震惊”的错误。

  4. A series of tests is designed to expose errors that will keep the build from properly performing its function. The intent should be to uncover “show-stopper” errors that have the highest likelihood of throwing the software project behind schedule.

  5. 该构建与其他构建集成,并且整个产品(以其当前形式)每天都会进行冒烟测试。集成方法可以是自上而下或自下而上的。

  6. The build is integrated with other builds, and the entire product (in its current form) is smoke tested daily. The integration approach may be top down or bottom up.

每天的测试频率可以让管理者和从业者对集成测试进度进行现实的评估。McConnell [McC96] 按以下方式描述烟雾测试:

The daily frequency of testing gives both managers and practitioners a realistic assessment of integration testing progress. McConnell [McC96] describes the smoke test in the following manner:

冒烟测试应该从头到尾对整个系统进行测试。它不必详尽无遗,但应该能够暴露主要问题。冒烟测试应该足够彻底,如果构建通过,您可以假设它足够稳定,可以进行更彻底的测试。

The smoke test should exercise the entire system from end to end. It does not have to be exhaustive, but it should be capable of exposing major problems. The smoke test should be thorough enough that if the build passes, you can assume that it is stable enough to be tested more thoroughly.

当烟雾测试应用于复杂的、时间紧迫的软件项目时,它具有许多好处:

Smoke testing provides a number of benefits when it is applied on complex, time-critical software projects:

  • 整合风险最小化。由于每天都会进行冒烟测试,因此可以及早发现不兼容性和其他严重错误,从而降低发现错误时对进度造成严重影响的可能性。

  • Integration risk is minimized. Because smoke tests are conducted daily, incompatibilities and other showstopper errors are uncovered early, thereby reducing the likelihood of serious schedule impact when errors are uncovered.

  • 最终产品的质量得到提高。由于该方法是面向构建(集成)的,因此冒烟测试可能会发现功能错误以及架构和组件级设计错误。如果及早纠正这些错误,将会产生更好的产品质量。

  • The quality of the end product is improved. Because the approach is construction (integration) oriented, smoke testing is likely to uncover functional errors as well as architectural and component-level design errors. If these errors are corrected early, better product quality will result.

  • 错误诊断和纠正得到简化。与所有集成测试方法一样,冒烟测试期间发现的错误可能与“新软件增量”相关,也就是说,刚刚添加到构建中的软件可能是新发现错误的原因。

  • Error diagnosis and correction are simplified. Like all integration testing approaches, errors uncovered during smoke testing are likely to be associated with “new software increments”—that is, the software that has just been added to the build(s) is a probable cause of a newly discovered error.

  • 进展更容易评估。随着时间的推移,越来越多的软件被集成,并且越来越多的软件被证明可以工作。这提高了团队士气,并向管理者提供了正在取得进展的良好迹象。

  • Progress is easier to assess. With each passing day, more of the software has been integrated and more has been demonstrated to work. This improves team morale and gives managers a good indication that progress is being made.

在某些方面,冒烟测试类似于回归测试(在第 20.3 节中讨论),这有助于确保新添加的组件不会干扰先前测试的现有组件的行为。为此,最好在添加新组件之前重新运行使用现有软件组件执行的测试用例的子集。重新运行测试用例所需的工作量并非微不足道,并且可以使用自动化测试来减少重新创建以重新运行这些测试用例的时间和工作量 [Net18]。对自动化测试的完整讨论超出了本章的范围,但是可以在本书的补充网页上找到代表性工具的链接。2第402页

In some ways smoke testing resembles regression testing (discussed in Section 20.3), which helps to ensure that the newly added components do not interfere with the behaviors of existing components that were previously tested. To do this, it is a good idea to rerun a subset of the test cases that executed with the existing software component before the new components were added. The effort required to rerun test cases is not trivial, and automated testing can be used to reduce the time and effort re-created to rerun these test cases [Net18]. A complete discussion of automated testing is beyond the scope of this chapter, but links to representative tools can be found on the Web pages that supplement this book.2Page 402

20.2.4 集成测试工作产品

20.2.4 Integration Test Work Products

软件集成的总体计划和特定测试的描述记录在测试规范中。该工作产品包含测试计划和测试过程,并成为软件配置的一部分。测试分为多个阶段和增量构建,以解决软件的特定功能和行为特征。例如,SafeHome安全系统的集成测试可能分为以下测试阶段:用户交互、传感器处理、通信功能和警报处理。

An overall plan for integration of the software and a description of specific tests is documented in a test specification. This work product incorporates a test plan and a test procedure and becomes part of the software configuration. Testing is divided into phases and incremental builds that address specific functional and behavioral characteristics of the software. For example, integration testing for the SafeHome security system might be divided into the following test phases: user interaction, sensor processing, communications functions, and alarm processing.

每个集成测试阶段都描绘了软件中广泛的功能类别,并且通常可以与软件架构中的特定领域相关。因此,软件增量被创建以对应于每个阶段。

Each integration test phase delineates a broad functional category within the software and generally can be related to a specific domain within the software architecture. Therefore, software increments are created to correspond to each phase.

集成时间表、脚手架软件的开发(第 19.2.1 节)以及相关主题也作为测试计划的一部分进行讨论。确定每个阶段的开始和结束日期,并定义单元测试模块的“可用窗口”。在制定项目进度表时,您必须考虑集成发生的方式,以便组件在需要时可用。脚手架软件(存根和驱动程序)的简要描述集中于可能需要特殊努力的特征。最后描述了测试环境和资源。不寻常的硬件配置、奇异的模拟器以及特殊的测试工具或技术是也可能讨论的许多主题中的几个。

A schedule for integration, the development of scaffolding software (Section 19.2.1), and related topics are also discussed as part of the test plan. Start and end dates for each phase are established, and “availability windows” for unit-tested modules are defined. When developing a project schedule, you’ll have to consider the manner in which integration occurs so that components will be available when needed. A brief description of scaffolding software (stubs and drivers) concentrates on characteristics that might require special effort. Finally, test environment and resources are described. Unusual hardware configurations, exotic simulators, and special test tools or techniques are a few of many topics that may also be discussed.

接下来描述完成测试计划所需的详细测试过程。描述了集成的顺序以及每个集成步骤的相应测试。还包括所有测试用例的列表(已注释以供后续参考)和预期结果。在敏捷世界中,这种级别的测试用例描述发生在开发实现用户故事的代码时,以便在准备好集成时可以立即测试代码。

The detailed testing procedure that is required to accomplish the test plan is described next. The order of integration and corresponding tests at each integration step are described. A listing of all test cases (annotated for subsequent reference) and expected results are also included. In the agile world, this level of test-case description occurs when code to implement the user story is being developed so the code can be tested as soon as it is ready for integration.

实际测试结果、问题或特性的历史记录在可以附加到测试规范的测试报告中通常最好将测试报告实现为共享 Web 文档,以允许所有利益相关者访问最新的测试结果和软件增量的当前状态。此在线文档中包含的信息对于开发人员在软件维护期间至关重要(第 4.9 节)。

A history of actual test results, problems, or peculiarities is recorded in a test report that can be appended to the test specification. It is often best to implement the test report as a shared Web document to allow all stakeholders access to the latest test results and the current state of the software increment. Information contained in this online document can be vital to developers during software maintenance (Section 4.9).

20.3 人工智能和回归测试

20.3 Artificial Intelligence and Regression Testing

每次作为集成测试的一部分添加新模块时,软件都会发生变化。新的数据流路径被建立,新的输入/输出(I/O)可能发生,并且新的控制逻辑被调用。与这些更改相关的副作用可能会导致以前完美运行的功能出现问题。在集成测试策略的上下文中,回归测试是重新执行已经进行的某些测试子集,以确保更改不会传播意外的副作用。每次对软件进行重大更改(包括新组件的集成)时都应执行回归测试。回归测试有助于确保更改(由于测试或其他原因)不会引入意外行为或其他错误。第403页

Each time a new module is added as part of integration testing, the software changes. New data flow paths are established, new input/output (I/O) may occur, and new control logic is invoked. Side effects associated with these changes may cause problems with functions that previously worked flawlessly. In the context of an integration test strategy, regression testing is the reexecution of some subset of tests that have already been conducted to ensure that changes have not propagated unintended side effects. Regression tests should be executed every time a major change is made to the software (including the integration of new components). Regression testing helps to ensure that changes (due to testing or for other reasons) do not introduce unintended behavior or additional errors.Page 403

回归测试可以通过重新执行所有测试用例的子集或使用自动捕获/回放工具来手动进行。捕获/回放工具使软件工程师能够捕获测试用例和结果以供后续回放和比较。回归测试套件(要执行的测试的子集)包含三个不同类别的测试用例:

Regression testing may be conducted manually, by reexecuting a subset of all test cases or using automated capture/playback tools. Capture/playback tools enable the software engineer to capture test cases and results for subsequent playback and comparison. The regression test suite (the subset of tests to be executed) contains three different classes of test cases:

  • 将执行所有软件功能的代表性测试样本

  • A representative sample of tests that will exercise all software functions

  • 针对可能受变更影响的软件功能的其他测试

  • Additional tests that focus on software functions that are likely to be affected by the change

  • 专注于已更改的软件组件的测试

  • Tests that focus on the software components that have been changed

随着集成测试的进行,回归测试的数量可能会变得相当大。因此,回归测试套件应设计为仅包含那些解决每个主要程序功能中的一类或多类错误的测试。

As integration testing proceeds, the number of regression tests can grow quite large. Therefore, the regression test suite should be designed to include only those tests that address one or more classes of errors in each of the major program functions.

Yoo 和 Harman [Yoo13] 撰写了有关人工智能 (AI) 在识别回归测试套件中使用的测试用例方面的潜在用途的文章。软件工具可以在添加新组件后检查软件增量中组件之间的依赖关系,并自动生成测试用例以用于回归测试。另一种可能性是使用机器学习技术来选择测试用例集,以优化组件协作错误的发现。这项工作很有希望,但仍然需要大量的人机交互来审查测试用例和建议的执行顺序。

Yoo and Harman [Yoo13] write about potential uses of artificial intelligence (AI) in identifying test cases for use in regression test suites. A software tool could examine the dependencies among the components in the software increment after the new components have been added and generate test cases automatically to use for regression testing. Another possibility would be using machine learning techniques to select sets of test cases that will optimize the discovery of component collaboration errors. This work is promising, but still requires significant human interaction to review the test cases and the recommended order for executing them.

20.4 OO环境中的集成测试

20.4 Integration Testing in the OO Context

面向对象的软件没有明显的层次控制结构,因此传统的自上而下和自下而上的集成策略(20.2节)意义不大。此外,一次将一个操作集成到一个类中(传统的增量集成方法)通常是不可能的,因为“构成类的组件之间存在直接和间接的交互”[Ber93]。

Object-oriented software does not have an obvious hierarchical control structure, so traditional top-down and bottom-up integration strategies (Section 20.2) have little meaning. In addition, integrating operations one at a time into a class (the conventional incremental integration approach) is often impossible because of the “direct and indirect interactions of the components that make up the class” [Ber93].

OO 系统的集成测试有两种不同的策略:基于线程的测试和基于使用的测试[Bin99]。第一个是基于线程的测试,集成了响应系统的一个输入或事件所需的一组类。每个线程都被单独集成和测试。应用回归测试以确保不会发生副作用。OO 软件集成测试的一个重要策略是基于线程的测试。线程是响应输入或事件的类集。

There are two different strategies for integration testing of OO systems: thread-based testing and use-based testing [Bin99]. The first, thread-based testing, integrates the set of classes required to respond to one input or event for the system. Each thread is integrated and tested individually. Regression testing is applied to ensure that no side effects occur. An important strategy for integration testing of OO software is thread-based testing. Threads are sets of classes that respond to an input or event.

第二种集成方法,基于使用的测试,通过测试那些使用很少(如果有)服务器类的类(称为独立类)来开始构建系统。在测试独立类之后,测试使用独立类的下一层类(称为依赖类) 。这种对依赖类的测试层的序列一直持续到整个系统构建完成为止。基于使用的测试侧重于不与其他类密切合作的类。

The second integration approach, use-based testing, begins the construction of the system by testing those classes (called independent classes) that use very few (if any) server classes. After the independent classes are tested, the next layer of classes, called dependent classes, that use the independent classes are tested. This sequence of testing layers of dependent classes continues until the entire system is constructed. Use-based tests focus on classes that do not collaborate heavily with other classes.

当进行面向对象系统的集成测试时,脚手架软件的使用也会发生变化。驱动程序可用于测试最低级别的操作以及测试整个类组。驱动程序也可以用来替换用户界面,以便可以在界面实现之前进行系统功能测试。存根可用于需要类之间协作但一个或多个协作类尚未完全实现的情况。

The use of scaffolding software also changes when integration testing of OO systems is conducted. Drivers can be used to test operations at the lowest level and for the testing of whole groups of classes. A driver can also be used to replace the user interface so that tests of system functionality can be conducted prior to implementation of the interface. Stubs can be used in situations in which collaboration between classes is required but one or more of the collaborating classes has not yet been fully implemented.

集群测试是面向对象软件集成测试的一个步骤。在这里,通过设计试图发现协作中错误的测试用例来执行一组协作类(通过检查 CRC 和对象关系模型来确定)。第405页

Cluster testing is one step in the integration testing of OO software. Here, a cluster of collaborating classes (determined by examining the CRC and object-relationship model) is exercised by designing test cases that attempt to uncover errors in the collaborations.Page 405

20.4.1 基于故障的测试用例设计3

20.4.1 Fault-Based Test-Case Design3

OO 系统中基于故障的测试的目标是设计很有可能发现似是而非的故障的测试。由于产品或系统必须符合客户要求,因此执行基于故障的测试所需的初步规划从分析模型开始。基于故障的测试策略是假设一组可能的故障,然后导出测试来证明每个假设。测试人员寻找可能的错误(即系统实现中可能导致缺陷的方面)。为了确定这些错误是否存在,设计了测试用例来测试设计或代码。

The object of fault-based testing within an OO system is to design tests that have a high likelihood of uncovering plausible faults. Because the product or system must conform to customer requirements, preliminary planning required to perform fault-based testing begins with the analysis model. The strategy for fault-based testing is to hypothesize a set of plausible faults and then derive tests to prove each hypothesis. The tester looks for plausible faults (i.e., aspects of the implementation of the system that may result in defects). To determine whether these faults exist, test cases are designed to exercise the design or code.

当然,这些技术的有效性取决于测试人员如何看待可能的错误。如果 OO 系统中的真实错误被认为是难以置信的,那么这种方法实际上并不比任何随机测试技术更好。然而,如果分析和设计模型可以深入了解可能出错的地方,那么基于故障的测试就可以以相对较低的工作量发现大量错误。

Of course, the effectiveness of these techniques depends on how testers perceive a plausible fault. If real faults in an OO system are perceived to be implausible, then this approach is really no better than any random testing technique. However, if the analysis and design models can provide insight into what is likely to go wrong, then fault-based testing can find significant numbers of errors with relatively low expenditures of effort.

集成测试寻找操作调用或消息连接中可能存在的错误。在此上下文中会遇到三种类型的故障:意外结果、使用错误的操作/消息以及不正确的调用。为了确定调用函数(操作)时可能出现的错误,必须检查操作的行为。

Integration testing looks for plausible faults in operation calls or message connections. Three types of faults are encountered in this context: unexpected result, wrong operation/message used, and incorrect invocation. To determine plausible faults as functions (operations) are invoked, the behavior of the operation must be examined.

集成测试适用于属性和操作。对象的“行为”由其属性分配的值定义。测试应该运用属性来确定不同类型的对象行为是否出现正确的值。

Integration testing applies to attributes as well as to operations. The “behaviors” of an object are defined by the values that its attributes are assigned. Testing should exercise the attributes to determine whether proper values occur for distinct types of object behavior.

需要注意的是,集成测试尝试查找客户端对象中的错误,而不是服务器中的错误。通俗地说,集成测试的重点是确定调用代码中是否存在错误,而不是被调用代码中是否存在错误。操作调用用作线索,是一种查找执行调用代码的测试需求的方法。

It is important to note that integration testing attempts to find errors in the client object, not the server. Stated in conventional terms, the focus of integration testing is to determine whether errors exist in the calling code, not the called code. The operation call is used as a clue, a way to find test requirements that exercise the calling code.

多类分区测试的方法类似于单个类的分区测试所使用的方法。单个类的划分如第 19.6.1 节中所述。但是,测试序列已扩展为包括通过消息调用到协作类的那些操作。另一种方法是根据特定类的接口来划分测试。参考图 20.3Bank类接收来自ATMCashier类的消息。因此,可以通过将银行内部的方法分为服务于ATM 的方法和服务于出纳员的方法来进行测试。

The approach for multiple-class partition testing is similar to the approach used for partition testing of individual classes. A single class is partitioned as discussed in Section 19.6.1. However, the test sequence is expanded to include those operations that are invoked via messages to collaborating classes. An alternative approach partitions tests based on the interfaces to a particular class. Referring to Figure 20.3, the Bank class receives messages from the ATM and Cashier classes. The methods within Bank can therefore be tested by partitioning them into those that serve ATM and those that serve Cashier.

图20.3 银行应用程序的类协作

Figure 20.3 Class collaboration diagram for banking application

资料来源:Kirani、Shekhar 和 Tsai,WT,“面向对象程序的规范和验证”,技术报告 TR 94-64,明尼苏达大学,1994 年 12 月 4 日,72。

Source: Kirani, Shekhar and Tsai, W. T., “Specification and Verification of Object-Oriented Programs,” Technical Report TR 94-64, University of Minnesota, December 4, 1994, 72.

Kirani 和 Tsai [Kir94] 建议按照以下步骤顺序生成多类随机测试用例:

Kirani and Tsai [Kir94] suggest the following sequence of steps to generate multiple-class random test cases:

  1. 对于每个客户端类,使用类操作列表生成一系列随机测试序列。这些操作将向其他服务器类发送消息。

  2. For each client class, use the list of class operations to generate a series of random test sequences. The operations will send messages to other server classes.

  3. 对于生成的每条消息,确定协作者类以及服务器对象中的相应操作。

  4. For each message that is generated, determine the collaborator class and the corresponding operation in the server object.

  5. 第406页对于服务器对象中的每个操作(已由客户端对象发送的消息调用),确定它传输的消息。

  6. Page 406For each operation in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits.

  7. 对于每条消息,确定调用的下一个操作级别并将它们合并到测试序列中。

  8. For each of the messages, determine the next level of operations that are invoked and incorporate these into the test sequence.

为了说明 [Kir94],请考虑Bank类相对于ATM类的一系列操作(图 20.3):

To illustrate [Kir94], consider a sequence of operations for the Bank class relative to an ATM class (Figure 20.3):

verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoREQ] n

verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoREQ]n

Bank类的随机测试用例可能是

A random test case for the Bank class might be

测试用例 r 3 = verifyAcct•verifyPIN•depositReq

Test case r3 = verifyAcct•verifyPIN•depositReq

为了考虑此测试中涉及的协作者,需要考虑与测试用例r 3中记录的每个操作相关的消息。银行必须与ValidationInfo合作执行verifyAcct()verifyPIN()。 银行必须与账户合作执行depositReq()。因此,执行这些协作的新测试用例是

To consider the collaborators involved in this test, the messages associated with each of the operations noted in test case r3 are considered. Bank must collaborate with ValidationInfo to execute the verifyAcct() and verifyPIN(). Bank must collaborate with Account to execute depositReq(). Hence, a new test case that exercises these collaborations is

20.4.2 基于场景的测试用例设计

20.4.2 Scenario-Based Test-Case Design

基于故障的测试会遗漏两种主要类型的错误:(1) 不正确的规范和 (2) 子系统之间的交互。当出现与不正确规格相关的错误时,产品就无法满足客户的需求。它可能会做错误的事情或忽略重要的功能。但无论哪种情况,质量(符合要求)都会受到影响。当一个子系统的行为造成导致另一子系统失败的情况(例如,事件、数据流)时,就会发生与子系统交互相关的错误。第407页

Fault-based testing misses two main types of errors: (1) incorrect specifications and (2) interactions among subsystems. When errors associated with an incorrect specification occur, the product doesn’t do what the customer wants. It might do the wrong thing or omit important functionality. But in either circumstance, quality (conformance to requirements) suffers. Errors associated with subsystem interaction occur when the behavior of one subsystem creates circumstances (e.g., events, data flow) that cause another subsystem to fail.Page 407

基于场景的测试将发现任何参与者与软件交互时发生的错误。基于场景的测试重点关注用户做什么,而不是产品做什么。这意味着捕获用户必须执行的任务(通过用例),然后应用它们及其变体作为测试。这与线程测试非常相似。

Scenario-based testing will uncover errors that occur when any actor interacts with the software. Scenario-based testing concentrates on what the user does, not what the product does. This means capturing the tasks (via use cases) that the user has to perform and then applying them and their variants as tests. This is very similar to thread testing.

场景测试可以发现交互错误。但要实现这一点,测试用例必须比基于故障的测试更复杂、更现实。基于场景的测试倾向于在一次测试中运用多个子系统(用户不会限制自己一次只能使用一个子系统)。

Scenario testing uncovers interaction errors. But to accomplish this, test cases must be more complex and more realistic than fault-based tests. Scenario-based testing tends to exercise multiple subsystems in a single test (users do not limit themselves to the use of one subsystem at a time).

随着面向对象系统的集成的开始,测试用例设计变得更加复杂。正是在这个阶段,必须开始测试类之间的协作。为了说明“类间测试用例生成”[Kir94],我们扩展了第 19.6 节中介绍的银行示例,以包括图 20.3中所示的类和协作。图中箭头的方向指示消息的方向,并且标签指示作为消息所隐含的协作的结果而调用的操作。

Test-case design becomes more complicated as integration of the object-oriented system begins. It is at this stage that testing of collaborations between classes must begin. To illustrate “interclass test-case generation” [Kir94], we expand the banking example introduced in Section 19.6 to include the classes and collaborations noted in Figure 20.3. The direction of the arrows in the figure indicates the direction of messages, and the labeling indicates the operations that are invoked as a consequence of the collaborations implied by the messages.

与单个班级的测试一样,班级协作测试可以通过应用随机和分区方法以及基于场景的测试和行为测试来完成。

Like the testing of individual classes, class collaboration testing can be accomplished by applying random and partitioning methods, as well as scenario-based testing and behavioral testing.

20.5 验证测试

20.5 Validation Testing

与所有测试步骤一样,验证试图发现错误,但重点是需求级别,即最终用户立即显而易见的事情。验证测试从集成测试的高潮开始,此时各个组件已被使用,软件已完全组装为一个包,并且接口错误已被发现并纠正。在验证或系统级别,不同软件类别之间的区别消失了。测试重点关注用户可见的操作和用户可识别的系统输出。

Like all testing steps, validation tries to uncover errors, but the focus is at the requirements level—on things that will be immediately apparent to the end user. Validation testing begins at the culmination of integration testing, when individual components have been exercised, the software is completely assembled as a package, and interfacing errors have been uncovered and corrected. At the validation or system level, the distinction between different software categories disappears. Testing focuses on user-visible actions and user-recognizable output from the system.

验证可以通过多种方式来定义,但一个简单(尽管很苛刻)的定义是,当软件以客户合理预期的方式运行时,验证就成功了。此时,一位久经沙场的软件开发人员可能会抗议:“谁或什么是合理期望的仲裁者?” 如果开发了软件需求规范,它会描述每个用户故事、所有用户可见的属性以及客户对每个故事的接受标准。客户的验收标准构成了验证测试方法的基础。

Validation can be defined in many ways, but a simple (albeit harsh) definition is that validation succeeds when software functions in a manner that can be reasonably expected by the customer. At this point, a battle-hardened software developer might protest: “Who or what is the arbiter of reasonable expectations?” If a software requirements specification has been developed, it describes each user story, all user-visible attributes, and the customer’s acceptance criteria for each. The customer’s acceptance criteria form the basis for a validation-testing approach.

软件验证是通过一系列证明符合要求的测试来实现的。测试计划概述了要进行的测试类别,测试程序定义了特定的测试用例,旨在确保满足所有功能要求,实现所有行为特征,所有内容准确且正确呈现,所有性能要求均得到满足。已达到,文档正确,并且满足可用性和其他要求(例如,可移植性、兼容性、错误恢复、可维护性)。如果发现与规范的偏差,则会创建缺陷列表。必须建立解决缺陷的方法(利益相关者可以接受的)。第 21 章讨论了这些非功能性需求的专门测试方法。第408页

Software validation is achieved through a series of tests that demonstrate conformity with requirements. A test plan outlines the classes of tests to be conducted, and a test procedure defines specific test cases that are designed to ensure that all functional requirements are satisfied, all behavioral characteristics are achieved, all content is accurate and properly presented, all performance requirements are attained, documentation is correct, and usability and other requirements are met (e.g., transportability, compatibility, error recovery, maintainability). If a deviation from specification is uncovered, a deficiency list is created. A method for resolving deficiencies (acceptable to stakeholders) must be established. Specialized testing methods for these nonfunctional requirements are discussed in Chapter 21.Page 408

验证过程的一个重要元素是配置审查。审查的目的是确保软件配置的所有元素都已正确开发、编目并具有支持支持活动所需的详细信息。配置审查(有时称为审核)将在第 22 章中进行更详细的讨论。

An important element of the validation process is a configuration review. The intent of the review is to ensure that all elements of the software configuration have been properly developed, are cataloged, and have the necessary detail to bolster the support activities. The configuration review, sometimes called an audit, is discussed in more detail in Chapter 22.

在验证或系统级别,类连接的细节消失了。OO 软件的验证侧重于用户可见的操作和用户可识别的系统输出。为了帮助推导验证测试,测试人员应该利用属于需求模型一部分的用例(第 7 章和第 8章) 。该用例提供了一个很有可能在用户交互需求中发现错误的场景。传统的黑盒测试方法(第 19 章)可用于驱动验证测试。此外,您可以选择从作为面向对象分析 (OOA) 一部分创建的对象行为模型中派生测试用例。

At the validation or system level, the details of class connections disappear. The validation of OO software focuses on user-visible actions and user-recognizable outputs from the system. To assist in the derivation of validation tests, the tester should draw upon use cases (Chapters 7 and 8) that are part of the requirements model. The use case provides a scenario that has a high likelihood of uncovered errors in user-interaction requirements. Conventional black-box testing methods (Chapter 19) can be used to drive validation tests. In addition, you may choose to derive test cases from the object-behavior model created as part of object-oriented analysis (OOA).

第409页

Page 409

20.6 测试模式

20.6 Testing Patterns

第 15 章讨论了使用模式作为描述特定设计问题的解决方案的机制。但模式也可用于为其他软件工程情况(在本例中为软件测试)提出解决方案。测试模式描述了常见的测试问题和可以帮助您处理这些问题的解决方案。

The use of patterns as a mechanism for describing solutions to specific design problems was discussed in Chapter 15. But patterns can also be used to propose solutions to other software engineering situations—in this case, software testing. Testing patterns describe common testing problems and solutions that can assist you in dealing with them.

即使在过去的十年里,大部分软件测试都是临时活动。测试模式是否可以帮助软件团队更有效地沟通测试,了解导致特定测试方法的动力,并将测试设计视为一种进化活动,其中每次迭代都会产生更完整的套件测试用例的数量,那么模式就已经取得了很大的成就。

Much of software testing, even during the past decade, has been an ad hoc activity. If testing patterns can help a software team to communicate about testing more effectively, to understand the motivating forces that lead to a specific approach to testing, and to approach the design of tests as an evolutionary activity in which each iteration results in a more complete suite of test cases, then patterns have accomplished much.

测试模式的描述方式与设计模式(第 15 章)非常相似。文献中已经提出了数十种测试模式(例如,[Mar02])。以下三种测试模式(仅以抽象形式呈现)提供了代表性示例:

Testing patterns are described in much the same way as design patterns (Chapter 15). Dozens of testing patterns have been proposed in the literature (e.g., [Mar02]). The following three testing patterns (presented in abstract form only) provide representative examples:

  • 模式名称: 配对测试

  • Pattern name: PairTesting

  • 摘要:结对测试是一种面向过程的模式,描述了一种类似于结对编程的技术[第 3 章],其中两个测试人员一起工作来设计和执行一系列可应用于单元、集成或验证测试活动的测试。

  • Abstract: A process-oriented pattern, pair testing describes a technique that is analogous to pair programming [Chapter 3] in which two testers work together to design and execute a series of tests that can be applied to unit, integration or validation testing activities.

  • 模式名称: SeparateTestInterface

  • Pattern name: SeparateTestInterface

  • 摘要:需要测试面向对象系统中的每个类,包括“内部类”(即,不向使用它们的组件外部公开任何接口的类)。separateTestInterface模式描述了如何创建“一个测试接口,可用于描述仅对组件内部可见的类的特定测试”[Lan01]。

  • Abstract: There is a need to test every class in an object-oriented system, including “internal classes” (i.e., classes that do not expose any interface outside of the component that used them). The SeparateTestInterface pattern describes how to create “a test interface that can be used to describe specific tests on classes that are visible only internally to a component” [Lan01].

  • 模式名称: 场景测试

  • Pattern name: ScenarioTesting

  • 摘要:一旦进行了单元和集成测试,就需要确定软件是否能够满足用户的需求。ScenarioTesting模式描述了一种从用户的角度来测试软件的技术此级别的故障表明该软件未能满足用户可见的要求 [Kan01]。

  • Abstract: Once unit and integration tests have been conducted, there is a need to determine whether the software will perform in a manner that satisfies users. The ScenarioTesting pattern describes a technique for exercising the software from the user’s point of view. A failure at this level indicates that the software has failed to meet a user visible requirement [Kan01].

对测试模式的全面讨论超出了本书的范围。如果您有进一步的兴趣,请参阅 [Bin99]、[Mar02]、[Tho04]、[Mac10] 和 [Gon17] 以获取有关此重要主题的更多信息。

A comprehensive discussion of testing patterns is beyond the scope of this book. If you have further interest, see [Bin99], [Mar02], [Tho04], [Mac10], and [Gon17] for additional information on this important topic.

20.7 总结

20.7 Summary

集成测试构建软件架构,同时进行测试以发现与软件组件之间的接口相关的错误。目标是采用经过单元测试的组件并构建由设计决定的程序结构。

Integration testing builds the software architecture while at the same time conducting tests to uncover errors associated with interfacing between software components. The objective is to take unit-tested components and build a program structure that has been dictated by design.

经验丰富的软件开发人员经常说:“测试永无止境;它只是从您[软件工程师]转移到您的客户。每次您的客户使用该程序时,都会进行测试。” 通过应用测试用例设计,您可以实现更完整的测试,从而在“客户测试”开始之前发现并纠正最多的错误。第410页

Experienced software developers often say, “Testing never ends; it just gets transferred from you [the software engineer] to your customer. Every time your customer uses the program, a test is being conducted.” By applying test-case design, you can achieve more complete testing and thereby uncover and correct the highest number of errors before the “customer’s tests” begin.Page 410

Hetzel [Het84] 将白盒测试描述为“小型测试”。他的意思是,本章中考虑的白盒测试通常适用于小型程序组件(例如,模块或小组模块)。另一方面,黑盒测试拓宽了您的关注范围,可以称为“大规模测试”。

Hetzel [Het84] describes white-box testing as “testing in the small.” His implication is that the white-box tests that have been considered in this chapter are typically applied to small program components (e.g., modules or small groups of modules). Black-box testing, on the other hand, broadens your focus and might be called “testing in the large.”

黑盒集成测试基于用户故事或某些其他分析建模表示中指定的需求。测试用例作者不需要等待组件实现代码编写完成,只要他们了解正在测试的组件所需的功能即可。验证测试通常通过黑盒测试用例来完成,黑盒测试用例产生最终用户可见的输入操作和可观察的输出行为。

Black-box integration testing is based on the requirements specified in the user stories or some other analysis modeling representation. Test-case authors do not need to wait for the component implementation code to be written, as long as they understand the required functionality of the components undergoing testing. Validation testing is often accomplished with black-box test cases that produce end-user visible input actions and observable output behaviors.

白盒测试需要仔细检查正在测试的组件的程序实现细节和数据结构实现细节。只有在组件级设计(或源代码)存在之后才能设计白盒测试。软件的逻辑路径以及组件之间的协作是白盒集成测试的重点。

White-box testing requires a close examination of procedural implementation details and data structure implementation details for the components undergoing testing. White-box tests can be designed only after component-level design (or source code) exists. Logical paths through the software and collaborations between components are the focus of white-box integration testing.

OO 软件的集成测试可以使用基于线程或基于使用的策略来完成。基于线程的测试集成了一组协作响应一个输入或事件的类。基于使用的测试从不使用服务器类的那些类开始分层构建系统。集成测试用例设计方法还可以利用随机测试和分区测试。此外,基于场景的测试和源自行为模型的测试可用于测试类及其协作者。测试序列跟踪跨类协作的操作流程。

Integration testing of OO software can be accomplished using a thread-based or use-based strategy. Thread-based testing integrates the set of classes that collaborate to respond to one input or event. Use-based testing constructs the system in layers, beginning with those classes that do not make use of server classes. Integration test-case design methods can also make use of random and partition tests. In addition, scenario-based testing and tests derived from behavioral models can be used to test a class and its collaborators. A test sequence tracks the flow of operations across class collaborations.

OO系统验证测试是面向黑盒的,可以通过应用与传统软件讨论的相同的黑盒方法来完成。然而,基于场景的测试主导着面向对象系统的验证,使用例成为验证测试​​的主要驱动力。

OO system validation testing is black-box oriented and can be accomplished by applying the same black-box methods discussed for conventional software. However, scenario-based testing dominates the validation of OO systems, making the use case a primary driver for validation testing.

回归测试是在对软件系统进行任何更改后重新执行所选测试用例的过程。每当向软件增量添加新组件或更改时,都应执行回归测试。回归测试有助于确保更改不会引入意外行为或其他错误。

Regression testing is the process of reexecuting a selected test case following any change made to a software system. Regression tests should be executed whenever new components or changes are added to a software increment. Regression testing helps to ensure that changes do not introduce unintended behavior or additional errors.

测试模式描述了常见的测试问题和可以帮助您处理这些问题的解决方案。如果测试模式可以帮助软件团队更有效地沟通测试,了解导致特定测试方法的动力,并将测试用例的设计视为一种进化活动,其中每次迭代都会产生更完整的结果如果有一套测试用例,那么模式就已经取得了很大的成就。

Testing patterns describe common testing problems and solutions that can assist you in dealing with them. If testing patterns can help a software team to communicate about testing more effectively, to understand the motivating forces that lead to a specific approach to testing, and to approach the design of test cases as an evolutionary activity in which each iteration results in a more complete suite of test cases, then patterns have accomplished much.

问题与思考点

Problems and Points to Ponder

20.1. 项目调度如何影响集成测试?

20.1. How can project scheduling affect integration testing?

20.2. 谁应该执行验证测试——软件开发人员还是软件用户?证明你的答案合理。

20.2. Who should perform validation testing—the software developer or the software user? Justify your answer.

第411页20.3。详尽的测试(即使对于非常小的程序是可能的)能否保证程序 100% 正确?

Page 41120.3. Will exhaustive testing (even if it is possible for very small programs) guarantee that a program is 100 percent correct?

20.4。为什么“测试”要从需求分析和设计开始?

20.4. Why should “testing” begin with requirements analysis and design?

20.5。非功能性需求(例如安全性或性能)是否应该作为集成测试的一部分进行测试?

20.5. Should nonfunctional requirements (e.g., security or performance) be tested as part of integration testing?

20.6。如果现有类已经经过彻底测试,为什么我们必须重新测试从现有类实例化的子类?

20.6. Why do we have to retest subclasses that are instantiated from an existing class, if the existing class has already been thoroughly tested?

20.7。基于线程和基于使用的集成测试策略有什么区别?

20.7. What is the difference between thread-based and use-based strategies for integration testing?

20.8。为本书前面讨论的SafeHome系统制定完整的测试策略。将其记录在测试规范中。

20.8. Develop a complete test strategy for the SafeHome system discussed earlier in this book. Document it in a test specification.

20.9。选择一个SafeHome系统用户故事作为基于场景的测试的基础,并构建一组为该用户故事进行集成测试所需的集成测试用例。

20.9. Pick one of the SafeHome system user stories to use as the basis of scenarios-based testing, and construct a set of integration test cases needed to do integration testing for that user story.

20.10。对于您在问题 20.9中编写的测试用例,确定将用于对添加到程序中的软件组件进行回归测试的测试用例子集。

20.10. For the test cases you wrote in Problem 20.9, identify a subset of test cases you will use for regression testing software components that are added to the program.

1术语“功能测试”“结构测试”有时分别用来代替黑盒测试和白盒测试。

1 The terms functional testing and structural testing are sometimes used in place of black-box and white-box testing, respectively.

2请参阅 SEPA 9e 网站。

2 See the SEPA 9e website.

3第 20.4.1 和 20.4.2 节改编自 Brian Marick 最初发布在互联网新闻组 comp.testing 上的文章。此改编已获得作者许可。有关这些主题的更多信息,请参阅 [Mar94]。应该注意的是,20.4.1 和 20.4.2 节中讨论的技术也适用于传统软件。

3 Sections 20.4.1 and 20.4.2 have been adapted from an article by Brian Marick originally posted on the Internet newsgroup comp.testing. This adaptation is included with the permission of the author. For further information on these topics, see [Mar94]. It should be noted that the techniques discussed in Sections 20.4.1 and 20.4.2 are also applicable for conventional software.

第412页

Page 412

章节

chapter

21软件测试——移动专业测试

21 Software Testing—Specialized Testing for Mobility

推动移动应用项目的同样紧迫感也遍及所有移动项目。利益相关者担心他们会错过市场窗口,并敦促将移动应用程序引入其目标市场。经常发生在流程后期的技术活动(例如性能和安全测试)有时会受到忽视。本应在设计阶段进行的可用性测试最终可能会被推迟到交付前。这些可能是灾难性的错误。为了避免这种情况,您和其他团队成员必须确保每个工作产品都具有高质量,否则用户将转向竞争产品 [Soa11]。

The same sense of urgency that drives MobileApp projects also pervades all mobility projects. Stakeholders are worried that they will miss a market window and press to introduce the MobileApp to its intended market. Technical activities that often occur late in the process, such as performance and security testing, are sometimes given short shrift. Usability testing that should occur during the design phase may end up being deferred until just before delivery. These can be catastrophic mistakes. To avoid this situation, you and other team members must ensure that each work product exhibits high quality, or users will move to a competing product [Soa11].

第413页移动应用程序需求和设计模型不能仅使用可执行测试用例进行测试。您和您的团队应该进行技术审查(第 16 章),检查可用性(第 12 章)以及移动应用程序的性能和安全性。

Page 413MobileApp requirements and design models cannot be tested solely with executable test cases. You and your team should conduct technical reviews (Chapter 16) that examine usability (Chapter 12) as well as MobileApp performance and security.

创建移动测试策略时需要问几个重要问题 [Sch09]:

There are several important questions to ask when creating a mobility testing strategy [Sch09]:

  • 在与用户进行测试之前,您是否必须构建一个功能齐全的原型?

  • Do you have to build a fully functional prototype before you test with users?

  • 您应该使用用户的设备进行测试还是提供测试设备?

  • Should you test with the user’s device or provide a device for testing?

  • 您应该在测试中包含哪些设备和用户组?

  • What devices and user groups should you include in testing?

  • 实验室测试与远程测试有何权衡?

  • What are the trade-offs associated with lab testing versus remote testing?

我们将在本章中逐一讨论这些问题。

We address each of these questions throughout this chapter.

21.1 移动测试指南

21.1 Mobile Testing Guidelines

完全在移动设备上运行的移动应用程序可以使用传统的软件测试方法进行测试(第 19 章和第 20章)。或者,可以使用在个人计算机上运行的模拟器来测试它们。当要测试瘦客户端 MobileApps 1时,事情会变得更加复杂。它们表现出许多与 Web 应用程序(第 20.2 节)中相同的测试挑战,但瘦客户端移动应用程序还存在与通过互联网网关和电话网络传输数据相关的额外问题[Was10]。

MobileApps that run entirely on a mobile device can be tested using traditional software testing methods (Chapters 19 and 20). Alternatively, they can be tested using emulators running on personal computers. Things become more complicated when thin-client MobileApps1 are to be tested. They exhibit many of the same testing challenges found in WebApps (Section 20.2), but thin-client MobileApps have the additional concerns associated with transmission of data through Internet gateways and telephone networks [Was10].

一般来说,用户期望移动应用能够感知上下文,并根据设备相对于可用网络功能的物理位置提供个性化的用户体验。在动态自组织网络中针对每种可能的设备和网络配置测试移动应用程序即使不是不可能,也是很困难的。

In general, users expect MobileApps to be context aware and deliver personalized user experiences based on the physical location of a device in relation to available network features. Testing MobileApps in dynamic ad hoc networks for every possible device and network configuration is difficult, if not impossible.

移动应用程序预计将提供桌面应用程序中的大部分复杂功能和可靠性,但它们驻留在资源相对有限的移动平台上。以下指南为移动应用程序测试提供了基础 [Kea07]:

MobileApps are expected to deliver much of the complex functionality and reliability found in desktop applications, but they are resident on mobile platforms with relatively limited resources. The following guidelines provide a basis for mobile application testing [Kea07]:

  • 在测试之前了解网络和设备情况以识别瓶颈(第 21.6 节)。

  • Understand the network and device landscape before testing to identify bottlenecks (Section 21.6).

  • 在不受控制的现实测试条件下进行测试(现场测试,第 21.8 节)。

  • Conduct tests in uncontrolled real-world test conditions (field-based testing, Section 21.8).

  • 选择正确的自动化测试工具(第 21.11 节)。

  • Select the right automation test tool (Section 21.11).

  • 使用加权设备平台矩阵方法来确定要测试的最关键的硬件/平台组合(第 21.8 节)。

  • Use the Weighted Device Platform Matrix method to identify the most critical hardware/platform combination to test (Section 21.8).

  • 至少检查一次所有可能平台中的端到端功能流程(第 21.10 节)。

  • Check the end-to-end functional flow in all possible platforms at least once (Section 21.10).

  • 第414页使用实际设备进行性能测试、GUI 测试和兼容性测试(第 21.821.11节)。

  • Page 414Conduct performance testing, GUI testing, and compatibility testing using actual devices (Sections 21.8 and 21.11).

  • 仅在无线流量和用户负载的实际条件下测量性能(第 21.8 节)。

  • Measure performance only in realistic conditions of wireless traffic and user load (Section 21.8).

21.2 测试策略

21.2 The Testing Strategies

移动应用程序测试策略采用所有软件测试的基本原则。然而,移动应用程序的独特性要求考虑许多专门问题:

The strategy for testing mobile applications adopts the basic principles for all software testing. However, the unique nature of MobileApps demands the consideration of a number of specialized issues:

  • 用户体验测试。用户尽早参与开发过程,以确保移动应用程序满足利益相关者对所有受支持设备的可用性和可访问性期望(第21.3 节)。

  • User-experience testing. Users are involved early in the development process to ensure that the MobileApp lives up to the usability and accessibility expectations of the stakeholders on all supported devices (Section 21.3).

  • 设备兼容性测试。测试人员验证 MobileApp 是否在所有必需的硬件和软件组合上正常工作(第 21.9 节)。

  • Device compatibility testing. Testers verify that the MobileApp works correctly on all required hardware and software combinations (Section 21.9).

  • 性能测试。测试人员检查移动设备特有的非功能性要求(例如,下载时间、处理器速度、存储容量、电源可用性)(第 21.8 节)。

  • Performance testing. Testers check nonfunctional requirements unique to mobile devices (e.g., download times, processor speed, storage capacity, power availability) (Section 21.8).

  • 连接性测试。测试人员确保 MobileApp 可以访问任何需要的网络或 Web 服务,并且可以容忍微弱或中断的网络访问(第 21.6 节)。

  • Connectivity testing. Testers ensure that the MobileApp can access any needed networks or Web services and can tolerate weak or interrupted network access (Section 21.6).

  • 安全测试。测试人员确保移动应用程序不会损害其用户的隐私或安全要求(第 21.7 节)。

  • Security testing. Testers ensure that the MobileApp does not compromise the privacy or security requirements of its users (Section 21.7).

  • 在野外进行测试。该应用程序在全球各种网络环境中的实际用户设备上的真实条件下进行了测试(第 21.9 节)。

  • Testing in the wild. The app is tested under realistic conditions on actual user devices in a variety of networking environments around the globe (Section 21.9).

  • 认证测试。测试人员确保移动应用程序符合分发它的应用程序商店制定的标准。

  • Certification testing. Testers ensure that the MobileApp meets the standards established by the app stores that will distribute it.

仅技术不足以保证移动应用程序的商业成功。如果移动应用程序运行不佳或达不到预期,用户会很快放弃它们。重要的是要记住,测试有两个重要目标:(1) 创建在开发周期早期发现缺陷的测试用例;(2) 验证重要质量属性的存在。移动应用程序的质量属性基于 ISO 2050:2011 [ISO17] 中规定的质量属性,涵盖功能、可靠性、可用性、效率、可维护性和可移植性(第 17 章

Technology alone is not sufficient to guarantee commercial success of a MobileApp. Users abandon MobileApps quickly if they do not work well or fail to meet expectations. It is important to recall that testing has two important goals: (1) to create test cases that uncover defects early in the development cycle and (2) to verify the presence of important quality attributes. The quality attributes for MobileApps are based on those set forth in ISO 2050:2011 [ISO17] and encompass functionality, reliability, usability, efficiency, maintainability, and portability (Chapter 17).

制定移动应用程序测试策略需要了解软件测试和使移动设备及其网络基础设施独一无二的挑战[Kho12a]。除了全面了解传统的软件测试方法(第 19 章和第 20章)之外,移动应用测试人员还应对电信原理有深入的了解,并了解移动操作系统平台的差异和功能。这些基础知识必须辅之以对不同类型的移动测试(例如,移动应用程序测试、移动手机测试、移动网站测试)、模拟器的使用、测试自动化工具和远程数据访问服务(RDA)的透彻理解。本章稍后将讨论每个主题。

Developing a MobileApp testing strategy requires an understanding of both software testing and the challenges that make mobile devices and their network infrastructure unique [Kho12a]. In addition to a thorough knowledge of conventional software testing approaches (Chapters 19 and 20), a MobileApp tester should have a good understanding of telecommunications principles and an awareness of the differences and capabilities of mobile operating systems platforms. This basic knowledge must be complemented with a thorough understanding of the different types of mobile testing (e.g., MobileApp testing, mobile handset testing, mobile website testing), the use of simulators, test automation tools, and remote data access services (RDA). Each of these topics is discussed later in this chapter.

第415页

Page 415

21.3 用户体验测试问题

21.3 User Experience Testing Issues

在产品提供相同功能的拥挤市场中,用户会选择最容易使用的移动应用程序。用户界面及其交互机制对 MobileApp 用户是可见的。测试移动应用程序提供的用户体验质量非常重要,以确保它满足用户的期望。

In a crowded marketplace in which products provide the same functionality, users will choose the MobileApp that is easiest to use. The user interface and its interaction mechanisms are visible to the MobileApp users. It is important to test the quality of the user experience provided by the MobileApp to ensure that it meets the expectations of its users.

移动应用程序可用性的哪些特征成为测试的重点,以及要解决哪些具体目标?第 12 章和第 13章中讨论的许多评估软件用户界面可用性的程序都可以用来评估移动应用程序。类似地,许多用于评估 Web 应用程序质量的策略(第 21.5 节)可用于测试移动应用程序的用户界面部分。构建良好的移动应用程序用户界面不仅仅是缩小现有桌面应用程序的用户界面大小。

What characteristics of MobileApp usability become the focus of testing, and what specific objectives are addressed? Many of the procedures for assessing the usability of software user interfaces discussed in Chapters 12 and 13 can be used to assess MobileApps. Similarly, many of the strategies used to assess the quality of WebApps (Section 21.5) may be used to test the user interface portion of the MobileApp. There is more to building a good MobileApp user interface than simply shrinking the size of a user interface from an existing desktop application.

21.3.1 手势测试

21.3.1 Gesture Testing

触摸屏在移动设备上无处不在,因此,开发人员添加了多点触控手势(例如,滑动、缩放、滚动、选择),作为在不损失屏幕空间的情况下增强用户交互可能性的一种手段。图 21.1显示了移动应用程序上的几种常见手势。不幸的是,手势密集型界面带来了许多审查和测试挑战。

Touch screens are ubiquitous on mobile devices, and, as a consequence, developers have added multitouch gestures (e.g., swiping, zooming, scrolling, selection) as a means of augmenting the user interaction possibilities without losing screen real estate. Figure 21.1 shows several commonly found gestures on MobileApps. Unfortunately, gesture-intensive interfaces present a number of review and testing challenges.

图21.1移动 应用手势

Figure 21.1 Mobile app gestures

纸质原型有时作为设计的一部分开发,不能用于充分审查手势的充分性或有效性。当测试开始时,很难使用自动化工具来测试触摸或手势界面操作。屏幕对象的位置受到屏幕尺寸和分辨率以及之前的用户操作的影响,这使得准确的手势测试变得困难。即使进行测试,也很难准确记录手势以供重播。第416页

Paper prototypes, sometimes developed as part of the design, cannot be used to adequately review the adequacy or efficacy of gestures. When testing is initiated, it’s difficult to use automated tools to test touch or gesture interface actions. The location of screen objects is affected by screen size and resolution, as well as previous user actions, making accurate gesture testing difficult. And even as testing is conducted, gestures are hard to log accurately for replay.Page 416

相反,测试人员需要创建测试框架程序来调用模拟手势事件的函数。所有这些都是昂贵且耗时的。

Instead, testers need to create test framework programs that make calls to functions that simulate gesture events. All of this is expensive and time consuming.

视障用户的辅助功能测试具有挑战性,因为手势界面通常不提供触觉或听觉反馈。手势的可用性和可访问性测试对于智能手机等无处不在的设备变得非常重要。当手势操作不可用时,测试设备的操作可能很重要。

Accessibility testing for visually impaired users is challenging because gesture interfaces typically do not provide either tactile or auditory feedback. Usability and accessibility testing for gestures become very important for ubiquitous devices like smartphones. It may be important to test the operation of the device when gesture operations are not available.

理想情况下,用户故事或用例编写得足够详细,以允许它们用作测试脚本的基础。招募代表性用户并纳入所有目标设备非常重要,以便在使用移动应用程序测试手势时考虑屏幕差异。最后,测试人员应确保手势符合为移动设备或平台设置的标准和上下文。

Ideally, user stories or use cases are written in sufficient detail to allow their use as the basis for test scripts. It is important to recruit representative users and include all targeted devices to take screen differences into account when testing gestures with a MobileApp. Finally, testers should ensure that the gestures conform to the standards and contexts set for the mobile device or platform.

21.3.2 虚拟键盘输入

21.3.2 Virtual Keyboard Input

由于虚拟键盘在激活时可能会遮挡部分显示屏,因此测试 MobileApp 以确保用户在打字时不会隐藏重要的屏幕信息非常重要。如果必须隐藏屏幕信息,则测试 MobileApp 允许用户翻页而不丢失键入信息的能力非常重要 [Sch09]。

Because a virtual keyboard may obscure part of the display screen when activated, it is important to test the MobileApp to ensure that important screen information is not hidden from the user while typing. If the screen information must be hidden, it is important to test the ability of the MobileApp to allow page flipping by the user without losing typed information [Sch09].

虚拟键盘通常比个人电脑键盘小,因此很难用 10 个手指打字。由于按键本身较小,更难敲击,并且不提供触觉反馈,因此必须对移动应用程序进行测试,以确保它可以轻松纠正错误,并且可以管理错误输入的单词而不会崩溃。

Virtual keyboards are typically smaller than personal computer keyboards, and therefore, it is difficult to type with 10 fingers. Because the keys themselves are smaller and harder to hit and provide no tactile feedback, the MobileApp must be tested to ensure that it allows easy error correction and can manage mistyped words without crashing.

预测技术(即自动完成部分键入的单词)通常与虚拟键盘一起使用,以帮助加快用户输入。如果移动应用程序是为全球市场设计的,那么测试用户选择的自然语言的单词补全的正确性非常重要。测试允许用户覆盖建议完成的任何机制的可用性也很重要。

Predictive technologies (i.e., autocompletion of partially typed words) are often used with virtual keyboards to help expedite user input. It is important to test the correctness of the word completions for the natural language chosen by the user, if the MobileApp is designed for a global market. It is also important to test the usability of any mechanism that allows the user to override a suggested completion.

虚拟键盘测试通常在可用性实验室中进行,但有些测试应该在野外进行。如果虚拟键盘测试发现重大问题,唯一的替代方案可能是确保 MobileApp 可以接受来自虚拟键盘以外的设备的输入(例如,物理键盘或语音输入)。

Virtual keyboard testing is often conducted in the usability laboratory, but some should be conducted in the wild. If virtual keyboard tests uncover significant problems, the only alternative may be to ensure that the MobileApp can accept input from devices other than a virtual keyboard (e.g., a physical keyboard or voice input).

21.3.3 语音输入与识别

21.3.3 Voice Input and Recognition

语音输入已成为在手忙脚乱的情况下提供输入和命令的越来越常见的方法。语音输入可以采用多种形式,处理每种形式需要不同程度的编程复杂性。当简单地录制消息以供稍后播放时,就会发生语音邮件输入。离散单词识别可用于允许用户从具有少量选择的菜单中口头选择项目。连续语音识别将口述语音转换为有意义的文本字符串。每种类型的语音输入都有其自己的测试挑战。第417页

Voice input has become an increasingly common method for providing input and commands in hands-busy, eyes-busy situations. Voice input may take several forms with different levels of programming complexity required to process each. Voice-mail input occurs when a message is simply recorded for playback later. Discrete word recognition can be used to allow users to verbally select items from a menu with a small number of choices. Continuous speech recognition translates dictated speech into meaningful text strings. Each type of voice input has its own testing challenges.Page 417

根据 Shneiderman [Shn09] 的说法,所有形式的语音输入和处理都会受到嘈杂环境的干扰的阻碍。与指向屏幕对象或按键相比,使用语音命令来控制设备会给用户带来更大的认知负担。用户必须想出正确的单词才能让移动应用程序执行所需的操作。然而,语音识别系统的广度和准确性正在迅速发展,语音识别很可能将成为许多移动应用程序中的主要通信形式。

According to Shneiderman [Shn09], all forms of voice input and processing are hindered by interference from noisy environments. Using voice commands to control a device impresses a greater cognitive load on the user, as compared to pointing to a screen object or pressing a key. The user must think of the correct word or words to get the MobileApp to perform the desired action. However, the breadth and accuracy of speech recognition systems are evolving rapidly, and it is likely the voice recognition will become the dominant form of communication in many MobileApps.

测试语音输入和识别的质量和可靠性应考虑环境条件和个人语音变化。错误将由移动应用程序的用户和处理输入的系统部分造成。应测试 MobileApp,以确保错误的输入不会导致 MobileApp 或设备崩溃。应涉及大量用户和环境,以确保移动应用程序以可接受的错误率运行。记录错误对于帮助开发人员提高 MobileApp 处理语音输入的能力非常重要。

Testing the quality and reliability of voice input and recognition should take environmental conditions and individual voice variation into account. Errors will be made by users of the MobileApp and by the portions of the system processing the input. The MobileApp should be tested to ensure that bad input does not crash the MobileApp or the device. Large numbers of users and environments should be involved to be sure the MobileApp is working with an acceptable error rate. It is important to log errors to help developers improve the ability of the MobileApp to process speech input.

21.3.4 警报和异常情况

21.3.4 Alerts and Extraordinary Conditions

当移动应用程序在实时环境中运行时,有一些因素可能会影响其行为。例如,当用户使用移动应用程序时,Wi-Fi 信号可能会丢失,或者可能会收到传入的短信、电话或日历警报。

When a MobileApp runs in a real-time environment, there are factors that may impact its behavior. For example, a Wi-Fi signal may be lost, or an incoming text message, phone call, or calendar alert may be received while the user is working with the MobileApp.

这些因素可能会扰乱移动应用程序用户的工作流程,但大多数用户选择在工作时允许警报和其他中断。移动应用程序测试环境必须能够模拟这些警报和条件。此外,您应该在实际设备上的生产环境中测试 MobileApp 处理警报和条件的能力(第 21.9 节)。

These factors can disrupt the MobileApp user’s work flow, yet most users opt to allow alerts and other interruptions as they work. A MobileApp test environment must be able to simulate these alerts and conditions. In addition, you should test the MobileApp’s ability to handle alerts and conditions in a production environment on actual devices (Section 21.9).

移动应用程序测试的一部分应重点关注与警报和弹出消息相关的可用性问题。测试应检查警报的清晰度和上下文、警报在设备显示屏上的位置的适当性,以及当涉及外语时,验证从一种语言到另一种语言的翻译是否正确。

Part of MobileApp testing should focus on the usability issues relating to alerts and pop-up messages. Testing should examine the clarity and context of alerts, the appropriateness of their location on the device display screen, and when foreign languages are involved, verification that the translation from one language to another is correct.

许多警报和条件可能会在各种移动设备上或通过网络或上下文变化以不同方式触发。尽管可以使用软件测试工具来模拟许多异常处理过程,但您不应仅依赖于开发环境中的测试。这再次强调了在实际设备上测试移动应用程序的重要性。

Many alerts and conditions may be triggered differently on various mobile devices or by network or context changes. Although many of the exception-handling processes can be simulated with a software test harness, you should not rely solely on testing in the development environment. This again emphasizes the importance of testing the MobileApp in the wild on actual devices.

许多基于计算机的系统必须从故障中恢复并在很少或根本没有停机的情况下恢复处理。在某些情况下,系统必须具有容错能力;也就是说,处理故障不得导致整个系统功能停止。在其他情况下,必须在指定的时间内纠正系统故障,否则将造成严重的经济损失。

Many computer-based systems must recover from faults and resume processing with little or no downtime. In some cases, a system must be fault tolerant; that is, processing faults must not cause overall system function to cease. In other cases, a system failure must be corrected within a specified period of time or severe economic damage will occur.

恢复测试是一种系统测试,它强制软件以各种方式失败并验证恢复是否正确执行。如果恢复是自动的(由系统本身执行),则会评估重新初始化、检查点机制、数据恢复和重新启动的正确性。如果恢复需要人工干预,则会评估平均修复时间 (MTTR),以确定其是否在可接受的限度内。

Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. If recovery is automatic (performed by the system itself), reinitialization, checkpointing mechanisms, data recovery, and restart are evaluated for correctness. If recovery requires human intervention, the mean time to repair (MTTR) is evaluated to determine whether it is within acceptable limits.

第418页

Page 418

21.4 Web应用程序测试

21.4 Web Application Testing

许多 Web 测试实践也适用于测试瘦客户端移动应用程序和交互式模拟。WebApp 测试策略采用所有软件测试的基本原则,并应用面向对象系统所使用的策略和策略。以下步骤总结了该方法:

Many Web testing practices are also appropriate for testing thin-client MobileApps and interactive simulations. The strategy for WebApp testing adopts the basic principles for all software testing and applies a strategy and tactics that are used for object-oriented systems. The following steps summarize the approach:

  1. 审查 WebApp 的内容模型以发现错误。

  2. The content model for the WebApp is reviewed to uncover errors.

  3. 审查接口模型以确保可以容纳所有用例。

  4. The interface model is reviewed to ensure that all use cases can be accommodated.

  5. 审查 WebApp 的设计模型以发现导航错误。

  6. The design model for the WebApp is reviewed to uncover navigation errors.

  7. 对用户界面进行测试以发现呈现和/或导航机制中的错误。

  8. The user interface is tested to uncover errors in presentation and/or navigation mechanics.

  9. 每个功能组件都经过单元测试。

  10. Each functional component is unit tested.

  11. 测试了整个架构的导航。

  12. Navigation throughout the architecture is tested.

  13. WebApp 在各种不同的环境配置中实现,并测试了与每种配置的兼容性。

  14. The WebApp is implemented in a variety of different environmental configurations and is tested for compatibility with each configuration.

  15. 进行安全测试是为了尝试利用 Web 应用程序或其环境中的漏洞。

  16. Security tests are conducted in an attempt to exploit vulnerabilities in the WebApp or within its environment.

  17. 进行性能测试。

  18. Performance tests are conducted.

  19. WebApp 由受控和监控的最终用户群体进行测试。他们与系统交互的结果将被评估是否存在错误。

  20. The WebApp is tested by a controlled and monitored population of end users. The results of their interaction with the system are evaluated for errors.

由于许多 Web 应用程序不断发展,因此测试过程是一项持续的活动,由支持人员执行,他们使用从首次设计 Web 应用程序时开发的测试派生的回归测试。第 21.5 节考虑了 WebApp 测试的方法。

Because many WebApps evolve continuously, the testing process is an ongoing activity, conducted by support staff who use regression tests derived from the tests developed when the WebApp was first engineered. Methods for WebApp testing are considered in Section 21.5.

21.5 Web 测试策略

21.5 Web Testing Strategies

测试是为了发现(并最终纠正)错误而运行软件的过程。这一基本理念首次在第 20 章中提出,对于 Web 应用程序来说并没有改变。事实上,由于基于 Web 的系统和应用程序驻留在网络上,并与许多不同的操作系统、浏览器(或其他个人通信设备)、硬件平台、通信协议和“后台”应用程序进行互操作,因此搜索错误意味着一个重要的任务。挑战。

Testing is the process of exercising software with the intent of finding (and ultimately correcting) errors. This fundamental philosophy, first presented in Chapter 20, does not change for WebApps. In fact, because Web-based systems and applications reside on a network and interoperate with many different operating systems, browsers (or other personal communication devices), hardware platforms, communications protocols, and “backroom” applications, the search for errors represents a significant challenge.

图 21.2将移动性测试过程与 Web 应用程序的设计金字塔(第 13 章)并置。请注意,随着测试流程从左到右、从上到下进行,首先测试 Web 应用程序设计的用户可见元素(金字塔的顶部元素),然后是基础设施设计元素。

Figure 21.2 juxtaposes the mobility testing process with the design pyramid for WebApps (Chapter 13). Note that as the testing flow proceeds from left to right and top to bottom, user-visible elements of the WebApp design (top elements of the pyramid) are tested first, followed by infrastructure design elements.

图21.2 测试流程

Figure 21.2 The testing process

由于许多应用程序不断发展,因此测试过程是一项持续的活动,由应用程序支持人员进行,他们使用从首次设计应用程序时开发的测试派生的回归测试。第419页

Because many apps evolve continuously, the testing process is an ongoing activity, conducted by app support staff who use regression tests derived from the tests developed when the app was first engineered.Page 419

21.5.1 内容测试

21.5.1 Content Testing

WebApp 内容中的错误可能像轻微的印刷错误一样微不足道,也可能像不正确的信息、不当的组织或违反知识产权法一样严重。内容测试试图在用户遇到这些问题和许多其他问题之前发现它们。

Errors in WebApp content can be as trivial as minor typographical mistakes or as significant as incorrect information, improper organization, or violation of intellectual property laws. Content testing attempts to uncover these and many other problems before the user encounters them.

内容测试具有三个重要目标:(1)发现基于文本的文档、图形表示和其他媒体中的语法错误(例如,拼写错误、语法错误);(2) 发现导航发生时呈现的任何内容对象中的语义错误(即信息的准确性或完整性方面的错误);(3) 查找呈现给最终用户的内容的组织或结构中的错误。

Content testing has three important objectives: (1) to uncover syntactic errors (e.g., typos, grammar mistakes) in text-based documents, graphical representations, and other media; (2) to uncover semantic errors (i.e., errors in the accuracy or completeness of information) in any content object presented as navigation occurs; and (3) to find errors in the organization or structure of content that is presented to the end user.

内容测试结合了审查和可执行测试用例的生成。尽管技术审查不是测试的一部分,但应该进行内容审查以确保内容的质量并发现语义错误。可执行测试用于发现内容错误,这些错误可以追溯到由从一个或多个数据库获取的数据驱动的动态派生内容。

Content testing combines both reviews and the generation of executable test cases. Although technical reviews are not a part of testing, content review should be performed to ensure that content has quality and to uncover semantic errors. Executable testing is used to uncover content errors that can be traced to dynamically derived content that is driven by data acquired from one or more databases.

为了实现第一个目标,可以使用自动拼写和语法检查器。然而,许多语法错误逃避了此类工具的检测,必须由人工审阅者(测试人员)发现。事实上,大型网站可能会寻求专业文案编辑的服务来发现印刷错误、语法错误、内容一致性错误、图形表示错误和交叉引用错误。

To accomplish the first objective, automated spelling and grammar checkers may be used. However, many syntactic errors evade detection by such tools and must be discovered by a human reviewer (tester). In fact, a large website might enlist the services of a professional copy editor to uncover typographical errors, grammatical mistakes, errors in content consistency, errors in graphical representations, and cross-referencing errors.

语义测试侧重于每个内容对象中呈现的信息。评审者(测试者)必须回答以下问题:

Semantic testing focuses on the information presented within each content object. The reviewer (tester) must answer the following questions:

  • 信息是否真实准确?

  • Is the information factually accurate?

  • 信息是否简明扼要?

  • Is the information concise and to the point?

  • 内容对象的布局是否易于用户理解?

  • Is the layout of the content object easy for the user to understand?

  • 嵌入在内容对象中的信息是否可以轻松找到?

  • Can information embedded within a content object be found easily?

  • 是否为从其他来源获得的所有信息提供了适当的参考?

  • Have proper references been provided for all information derived from other sources?

  • 所呈现的信息内部一致并且与其他内容对象中呈现的信息一致吗?第421页

  • Is the information presented consistent internally and consistent with information presented in other content objects?Page 421

  • 内容是否具有冒犯性、误导性,或者是否会引发诉讼?

  • Is the content offensive, misleading, or does it open the door to litigation?

  • 内容是否侵犯现有版权或商标?

  • Does the content infringe on existing copyrights or trademarks?

  • 内容是否包含补充现有内容的内部链接?链接正确吗?

  • Does the content contain internal links that supplement existing content? Are the links correct?

  • 内容的审美风格与界面的审美风格是否冲突?

  • Does the aesthetic style of the content conflict with the aesthetic style of the interface?

为大型 Web 应用程序(包含数百个内容对象)获取上述每个问题的答案可能是一项艰巨的任务。然而,未能发现语义错误将动摇用户对 Web 应用程序的信心,并可能导致基于 Web 的应用程序失败。

Obtaining answers to each of these questions for a large WebApp (containing hundreds of content objects) can be a daunting task. However, failure to uncover semantic errors will shake the user’s faith in the WebApp and can lead to failure of the Web-based application.

21.5.2 接口测试

21.5.2 Interface Testing

界面测试练习交互机制并验证用户界面的美学方面。界面测试的总体策略是(1)发现与特定界面机制相关的错误(例如,正确执行菜单链接或在表单中输入数据的方式中的错误)和(2)发现与特定界面机制相关的错误。接口实现导航、WebApp 功能或内容显示的语义。除了面向 WebApp 的细节之外,此处提到的接口策略适用于所有类型的客户端-服务器软件。为了实现这一战略,启动了许多战术步骤:

Interface testing exercises interaction mechanisms and validates aesthetic aspects of the user interface. The overall strategy for interface testing is to (1) uncover errors related to specific interface mechanisms (e.g., errors in the proper execution of a menu link or the way data are entered in a form) and (2) uncover errors in the way the interface implements the semantics of navigation, WebApp functionality, or content display. With the exception of WebApp-oriented specifics, the interface strategy noted here is applicable to all types of client-server software. To accomplish this strategy, a number of tactical steps are initiated:

  • 界面功能经过测试,以确保设计规则、美观和相关视觉内容可供用户使用,没有错误。

  • Interface features are tested to ensure that design rules, aesthetics, and related visual content are available for the user without error.

  • 各个接口机制的测试方式类似于单元测试。例如,测试旨在执行所有表单、客户端脚本、动态 HTML、脚本、流内容和特定于应用程序的接口机制(例如,电子商务应用程序的购物车)。

  • Individual interface mechanisms are tested in a manner that is analogous to unit testing. For example, tests are designed to exercise all forms, client-side scripting, dynamic HTML, scripts, streaming content, and application-specific interface mechanisms (e.g., a shopping cart for an e-commerce application).

  • 每个接口机制都在特定用户类别的用例或网络语义单元(NSU)(第13章)的上下文中进行测试。

  • Each interface mechanism is tested within the context of a use case or network semantic unit (NSU) (Chapter 13) for a specific user category.

  • 针对选定的用例和 NSU 测试完整的界面,以发现界面语义中的错误。正是在这个阶段进行了一系列可用性测试。

  • The complete interface is tested against selected use cases and NSUs to uncover errors in the semantics of the interface. It is at this stage that a series of usability tests are conducted.

  • 该界面在各种环境(例如浏览器)中进行了测试,以确保其兼容。

  • The interface is tested within a variety of environments (e.g., browsers) to ensure that it will be compatible.

21.5.3 导航测试

21.5.3 Navigation Testing

用户浏览 WebApp 的方式与访客浏览商店或博物馆的方式大致相同。有很多路要走,有很多停留,有很多东西要学习和观察,有很多活动要发起,有很多决定要做出。这个导航过程是可预测的,因为每个访问者到达时都有一组目标。同时,导航过程可能是不可预测的,因为访问者受到她看到或学到的东西的影响,可能会选择一条路径或发起一个与原始目标不典型的操作。导航测试的工作是 (1) 确保允许 WebApp 用户浏览 WebApp 的机制全部正常运行,以及 (2) 验证每个 NSU 是否可以通过适当的用户类别来实现。第422页

A user travels through a WebApp in much the same way as a visitor walks through a store or museum. There are many pathways to take, stops to make, things to learn and look at, activities to initiate, and decisions to make. This navigation process is predictable in the sense that every visitor has a set of objectives when he arrives. At the same time, the navigation process can be unpredictable because the visitor, influenced by something she sees or learns, may choose a path or initiate an action that is not typical for the original objective. The job of navigation testing is (1) to ensure that the mechanisms that allow the WebApp user to travel through the WebApp are all functional and (2) to validate that each NSU can be achieved by the appropriate user category.Page 422

导航测试的第一阶段实际上是在界面测试期间开始的。导航机制(所有类型的链接和锚点、重定向、2 个书签、框架和框架集、站点地图以及内部搜索设施的准确性)经过测试,以确保每个机制都能执行其预期功能。所提到的一些测试可以通过自动化工具(例如链接检查)执行,而其他测试则手动设计和执行。整个目的是确保在 Web 应用程序上线之前发现导航机制中的错误。

The first phase of navigation testing actually begins during interface testing. Navigation mechanisms (links and anchors of all types, redirects,2 bookmarks, frames and frame sets, site maps, and the accuracy of internal search facilities) are tested to ensure that each performs its intended function. Some of the tests noted can be performed by automated tools (e.g., link checking), while others are designed and executed manually. The intent throughout is to ensure that errors in navigation mechanics are found before the WebApp goes online.

每个 NSU(第 13 章)由一组连接导航节点(例如网页、内容对象或功能)的导航路径(称为“用户旅程”)定义。总体而言,每个 NSU 都允许用户实现由用户类别的一个或多个用例定义的特定要求。导航测试对每个 NSU 进行测试,以确保能够实现这些要求。如果 NSU 尚未作为 WebApp 分析或设计的一部分创建,您可以应用用例来设计导航测试用例。在测试每个 NSU 或用例时,您应该回答以下问题:

Each NSU (Chapter 13) is defined by a set of navigation paths (called “the user journey”) that connect navigation nodes (e.g., Web pages, content objects, or functionality). Taken as a whole, each NSU allows a user to achieve specific requirements defined by one or more use cases for a user category. Navigation testing exercises each NSU to ensure that these requirements can be achieved. If NSUs have not been created as part of WebApp analysis or design, you can apply use cases for the design of navigation test cases. You should answer the following questions as each NSU or use case is tested:

  • NSU 是否已完全实现且没有错误?

  • Is the NSU achieved in its entirety without error?

  • 每个导航节点(为 NSU 定义)在为 NSU 定义的导航路径的上下文中是否可达?

  • Is every navigation node (defined for an NSU) reachable within the context of the navigation paths defined for the NSU?

  • 如果可以使用多个导航路径来实现 NSU,是否对每条相关路径都进行了测试?

  • If the NSU can be achieved using more than one navigation path, has every relevant path been tested?

  • 如果用户界面提供指导来协助导航,那么随着导航的进行,方向是否正确且易于理解?

  • If guidance is provided by the user interface to assist in navigation, are directions correct and understandable as navigation proceeds?

  • 是否有一种机制(除了浏览器“后退”箭头之外)用于返回到前一个导航节点和导航路径的开头?

  • Is there a mechanism (other than the browser “back” arrow) for returning to the preceding navigation node and to the beginning of the navigation path?

  • 大型导航节点(即长网页)内的导航机制是否正常工作?

  • Do mechanisms for navigation within a large navigation node (i.e., a long Web page) work properly?

  • 如果某个功能要在节点执行并且用户选择不提供输入,NSU 的其余部分是否可以完成?

  • If a function is to be executed at a node and the user chooses not to provide input, can the remainder of the NSU be completed?

  • 如果某个节点执行函数,函数处理出现错误,NSU能否完成?

  • If a function is executed at a node and an error in function processing occurs, can the NSU be completed?

  • 有没有办法在到达所有节点之前停止导航,然后返回到导航停止的位置并从那里继续?

  • Is there a way to discontinue the navigation before all nodes have been reached, but then return to where the navigation was discontinued and proceed from there?

  • 是否可以从站点地图访问每个节点?节点名称对最终用户有意义吗?

  • Is every node reachable from the site map? Are node names meaningful to end users?

  • 如果从某个外部源到达 NSU 内的节点,是否可以处理到导航路径上的下一个节点?是否可以返回到导航路径上的上一个节点?

  • If a node within an NSU is reached from some external source, is it possible to process to the next node on the navigation path? Is it possible to return to the previous node on the navigation path?

  • 当 NSU 执行时,用户是否了解自己在内容架构中的位置?第423页

  • Does the user understand his location within the content architecture as the NSU is executed?Page 423

导航测试,如界面和可用性测试,应该由尽可能多的不同群体进行。您负责导航测试的早期阶段,但后期阶段应由其他项目利益相关者、独立测试团队以及最终由非技术用户执行。目的是彻底练习 WebApp 导航。

Navigation testing, like interface and usability testing, should be conducted by as many different constituencies as possible. You have responsibility for early stages of navigation testing, but later stages should be conducted by other project stakeholders, an independent testing team, and ultimately, by nontechnical users. The intent is to exercise WebApp navigation thoroughly.

21.6 国际化

21.6 Internationalization

国际化是创建软件产品的过程,使其可以在多个国家/地区以多种语言使用,而无需进行任何工程更改。本地化是通过添加特定于区域设置的要求并将文本元素翻译为适当的语言来调整软件应用程序以在全球目标区域使用的过程。除了语言差异之外,本地化工作还可能涉及考虑每个国家的货币、文化、税收和标准(技术和法律)[Sla12]。在世界许多地方推出移动应用而不进行测试是非常愚蠢的。

Internationalization is the process of creating a software product so that it can be used in several countries and with various languages without requiring any engineering changes. Localization is the process of adapting a software application for use in targeted global regions by adding locale-specific requirements and translating text elements to appropriate languages. Localization effort may involve taking each country’s currency, culture, taxes, and standards (both technical and legal) into account in addition to differences in languages [Sla12]. Launching a MobileApp in many parts of the world without testing it there would be very foolish.

由于在每个计划本地化的国家/地区建立内部测试设施的成本可能非常高,因此将测试外包给每个国家/地区的本地供应商通常更具成本效益[Reu12]。然而,使用外包方法可能会导致移动应用程序开发团队与执行本地化测试的人员之间的沟通恶化。

Because it can be very costly to build an in-house testing facility in each country for which localization is planned, outsourcing testing to local vendors in each country is often more cost effective [Reu12]. However, using an outsourcing approach risks a degradation of communication between the MobileApp development team and those who are performing localization tests.

众包已在许多在线社区中变得流行。3 Reuveni [Reu12] 建议可以利用众包来吸引分散在开发环境之外的全球各地的本地化测试人员。为了实现这一目标,找到一个以其声誉为荣并拥有成功记录的社区非常重要。易于使用的实时平台允许社区成员与项目决策者进行沟通。为了保护知识产权,只有愿意签署保密协议的值得信赖的社区成员才可以参与。

Crowdsourcing has become popular in many online communities.3 Reuveni [Reu12] suggests that crowdsourcing could be used to engage localization testers dispersed around the globe outside of the development environment. To accomplish this, it is important to find a community that prides itself on its reputation and has a track record of successes. An easy-to-use real-time platform allows community members to communicate with the project decision makers. To protect intellectual property, only trustworthy community members who are willing to sign nondisclosure agreements are allowed to participate.

21.7 安全测试

21.7 Security Testing

任何管理敏感信息或导致可能不当伤害(或使个人受益)的行为的基于计算机的系统都是不当或非法渗透的目标。渗透涵盖了广泛的活动:试图渗透体育系统的黑客、试图渗透以进行报复的心怀不满的员工、试图渗透以获取非法个人利益的不诚实的个人。

Any computer-based system that manages sensitive information or causes actions that can improperly harm (or benefit) individuals is a target for improper or illegal penetration. Penetration spans a broad range of activities: hackers who attempt to penetrate systems for sport, disgruntled employees who attempt to penetrate for revenge, dishonest individuals who attempt to penetrate for illicit personal gain.

安全测试试图验证系统内置的保护机制实际上可以保护系统免受不当渗透。如果有足够的时间和资源,彻底的安全测试最终将渗透到系统中。系统设计者的作用是使渗透成本大于将获得的信息的价值。第 18 章更详细地讨论了安全保证和安全工程。第424页

Security testing attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration. Given enough time and resources, thorough security testing will ultimately penetrate a system. The role of the system designer is to make penetration cost more than the value of the information that will be obtained. Security assurance and security engineering are discussed in more detail in Chapter 18.Page 424

移动安全是一个复杂的主题,在完成有效的安全测试之前必须充分理解它。4移动应用程序及其所在的客户端和服务器端环境对于外部黑客、心怀不满的员工、不诚实的竞争对手以及任何其他希望窃取敏感信息、恶意修改内容、降低性能、禁用功能的人来说都是一个有吸引力的目标,或使个人、组织或企业难堪。

Mobile security is a complex subject that must be fully understood before effective security testing can be accomplished.4 MobileApps and the client-side and server-side environments in which they are housed represent an attractive target for external hackers, disgruntled employees, dishonest competitors, and anyone else who wishes to steal sensitive information, maliciously modify content, degrade performance, disable functionality, or embarrass a person, organization, or business.

安全测试旨在探测客户端环境、数据从客户端传递到服务器并再次返回时发生的网络通信以及服务器端环境的漏洞。这些域中的每一个都可能受到攻击,安全测试人员的工作就是发现可能被有意这样做的人利用的弱点。

Security tests are designed to probe vulnerabilities of the client-side environment, the network communications that occur as data are passed from client to server and back again, and the server-side environment. Each of these domains can be attacked, and it is the job of the security tester to uncover weaknesses that can be exploited by those with the intent to do so.

在客户端,漏洞通常可以追溯到浏览器、电子邮件程序或通信软件中预先存在的错误。在服务器端,漏洞包括拒绝服务攻击和恶意脚本,这些攻击可以传递到客户端或用于禁用服务器操作。此外,服务器端数据库可以在未经授权的情况下被访问(数据盗窃)。

On the client side, vulnerabilities can often be traced to preexisting bugs in browsers, e-mail programs, or communication software. On the server side, vulnerabilities include denial-of-service attacks and malicious scripts that can be passed along to the client side or used to disable server operations. In addition, server-side databases can be accessed without authorization (data theft).

为了防止这些(以及许多其他)漏洞,可以使用防火墙、身份验证、加密和授权技术。安全测试的目的应该是探测这些安全技术,以发现安全漏洞。

To protect against these (and many other) vulnerabilities, firewalls, authentication, encryption, and authorization techniques can be used. Security tests should be designed to probe each of these security technologies in an effort to uncover security holes.

安全测试的实际设计需要深入了解每个安全元素的内部工作原理,并全面了解各种网络技术。如果移动应用程序或 Web 应用程序对业务至关重要、维护敏感数据或可能成为黑客的目标,那么最好将安全测试外包给专门从事该领域的供应商。

The actual design of security tests requires in-depth knowledge of the inner workings of each security element and a comprehensive understanding of a full range of networking technologies. If the MobileApp or WebApp is business critical, maintains sensitive data, or is a likely target of hackers, it’s a good idea to outsource security testing to a vendor who specializes in it.

21.8 性能测试

21.8 Performance Testing

对于实时和嵌入式系统,提供所需功能但不符合性能要求的软件是不可接受的。性能测试旨在测试集成系统环境中软件的运行时性能。性能测试贯穿测试过程的所有步骤。即使在单元级别,也可以在进行测试时评估单个模块的性能。然而,直到所有系统元件完全集成后才能确定系统的真实性能。

For real-time and embedded systems, software that provides required functionality but does not conform to performance requirements is unacceptable. Performance testing is designed to test the run-time performance of software within the context of an integrated system. Performance testing occurs throughout all steps in the testing process. Even at the unit level, the performance of an individual module may be assessed as tests are conducted. However, it is not until all system elements are fully integrated that the true performance of a system can be ascertained.

没有什么比移动应用程序需要几分钟才能加载内容更令人沮丧的了,而竞争对手的应用程序只需几秒钟即可下载类似的内容。没有什么比尝试登录 Web 应用程序并收到“服务器繁忙”消息并建议您稍后重试更令人恼火的了。没有什么比移动应用程序或 Web 应用程序在某些情况下立即响应而在其他情况下似乎进入无限等待状态更令人不安的了。所有这些事件每天都在 Web 上发生,并且都与性能相关。第425页

Nothing is more frustrating than a MobileApp that takes minutes to load content when competitive apps download similar content in seconds. Nothing is more aggravating than trying to log on to a WebApp and receiving a “server-busy” message, with the suggestion that you try again later. Nothing is more disconcerting than a MobileApp or WebApp that responds instantly in some situations and then seems to go into an infinite wait state in other situations. All of these occurrences happen on the Web every day, and all of them are performance related.Page 425

性能测试用于发现由于服务器端资源缺乏、网络带宽不合适、数据库功能不足、操作系统功能错误或薄弱、WebApp 功能设计不当以及其他可能导致以下问题而导致的性能问题:客户端-服务器性能下降。其目的有两个:(1) 了解系统在加载时如何响应(即用户数量、事务数量或总体数据量),以及 (2) 收集将导致设计修改以提高性能的指标。

Performance testing is used to uncover performance problems that can result from a lack of server-side resources, inappropriate network bandwidth, inadequate database capabilities, faulty or weak operating system capabilities, poorly designed WebApp functionality, and other hardware or software issues that can lead to degraded client-server performance. The intent is twofold: (1) to understand how the system responds as loading (i.e., number of users, number of transactions, or overall data volume), and (2) to collect metrics that will lead to design modifications to improve performance.

性能测试通常与压力测试结合在一起,通常需要硬件和软件仪器。也就是说,通常需要以精确的方式测量资源利用率(例如,处理器周期)。外部仪器可以监视执行间隔、记录发生的事件(例如中断)以及定期对机器状态进行采样。通过检测系统,测试人员可以发现导致性能下降和可能的系统故障的情况。

Performance tests are often coupled with stress testing and usually require both hardware and software instrumentation. That is, it is often necessary to measure resource utilization (e.g., processor cycles) in an exacting fashion. External instrumentation can monitor execution intervals, log events (e.g., interrupts) as they occur, and sample machine states on a regular basis. By instrumenting a system, the tester can uncover situations that lead to degradation and possible system failure.

移动应用程序性能的某些方面(至少在最终用户看来)是难以测试的。网络加载、网络接口硬件的变幻莫测以及类似问题在客户端或浏览器级别不容易进行测试。移动性能测试旨在模拟现实世界的负载情况。随着同时应用程序用户数量的增加,或在线交易数量的增加,或数据量(下载或上传)的增加,性能测试将有助于回答以下问题:

Some aspects of MobileApp performance, at least as the end user perceives it, are difficult to test. Network loading, the vagaries of network interfacing hardware, and similar issues are not easily tested at the client or browser level. Mobile performance tests are designed to simulate real-world loading situations. As the number of simultaneous app users grows, or the number of online transactions increases, or the amount of data (downloaded or uploaded) increases, performance testing will help answer the following questions:

  • 服务器响应时间是否降低到明显且不可接受的程度?

  • Does the server response time degrade to a point where it is noticeable and unacceptable?

  • 在什么时候(就用户、事务或数据加载而言)性能会变得不可接受?

  • At what point (in terms of users, transactions, or data loading) does performance become unacceptable?

  • 哪些系统组件会导致性能下降?

  • What system components are responsible for performance degradation?

  • 各种负载条件下用户的平均响应时间是多少?

  • What is the average response time for users under a variety of loading conditions?

  • 性能下降对系统安全有影响吗?

  • Does performance degradation have an impact on system security?

  • 随着系统负载的增加,应用程序的可靠性或准确性是否会受到影响?

  • Is app reliability or accuracy affected as the load on the system grows?

  • 当应用的负载大于最大服务器容量时会发生什么?

  • What happens when loads that are greater than maximum server capacity are applied?

  • 业绩下降对公司收入有影响吗?

  • Does performance degradation have an impact on company revenues?

为了找到这些问题的答案,进行了两种不同的性能测试:(1)负载测试检查各种负载水平和各种组合下的实际负载,(2)压力测试将负载增加到断点来确定应用程序环境可以处理的容量。

To develop answers to these questions, two different performance tests are conducted: (1) load testing examines real-world loading at a variety of load levels and in a variety of combinations, and (2) stress testing forces loading to be increased to the breaking point to determine how much capacity the app environment can handle.

负载测试的目的是确定 WebApp 及其服务器端环境如何响应各种负载条件。随着测试的进行,以下变量的排列定义了一组测试条件:

The intent of load testing is to determine how the WebApp and its server-side environment will respond to various loading conditions. As testing proceeds, permutations to the following variables define a set of test conditions:

N、并发用户数

N, number of concurrent users

T,单位时间在线交易数

T, number of online transactions per unit of time

D、服务器每次事务处理的数据负载第426页

D, data load processed by the server per transactionPage 426

在每种情况下,这些变量都是在系统的正常操作范围内定义的。运行每个测试条件时,会收集以下一项或多项指标:平均用户响应、下载标准化数据单元的平均时间或处理事务的平均时间。您应该检查这些措施,以确定性能的急剧下降是否可以追溯到N、TD的特定组合。

In every case, these variables are defined within normal operating bounds of the system. As each test condition is run, one or more of the following measures are collected: average user response, average time to download a standardized unit of data, or average time to process a transaction. You should examine these measures to determine whether a precipitous decrease in performance can be traced to a specific combination of N, T, and D.

负载测试还可用于评估为 Web 应用程序用户推荐的连接速度。总吞吐量P按以下方式计算:

Load testing can also be used to assess recommended connection speeds for users of the WebApp. Overall throughput, P, is computed in the following manner:

P = N × T × D

P = N × T × D

举个例子,考虑一个流行的体育新闻网站。在给定时刻,20,000 个并发用户平均每 2 分钟提交一次请求(事务,T )。每笔交易都需要 WebApp 下载一篇平均长度为 3K 字节的新文章。因此,吞吐量可以计算为:

As an example, consider a popular sports news site. At a given moment, 20,000 concurrent users submit a request (a transaction, T) once every 2 minutes on average. Each transaction requires the WebApp to download a new article that averages 3K bytes in length. Therefore, throughput can be calculated as:

因此,服务器的网络连接必须支持此数据速率,并且应该进行测试以确保它能够支持。

The network connection for the server would therefore have to support this data rate and should be tested to ensure that it does.

移动应用程序的压力测试试图发现极端操作条件下会发生的错误。此外,它还提供了一种机制来确定 MobileApp 是否会在不影响安全性的情况下正常降级。可能造成极端情况的众多行为包括:(1) 在同一设备上运行多个移动应用程序,(2) 用病毒或恶意软件感染系统软件,(3) 尝试接管设备并用其传播垃圾邮件, (4) 迫使移动应用程序处理异常大量的交易,以及 (5) 在设备上存储异常大量的数据。当遇到这些情况时,将检查移动应用程序以确保正确处理资源密集型服务(例如流媒体)。

Stress testing for mobile apps attempts to find errors that will occur under extreme operating conditions. In addition, it provides a mechanism for determining whether the MobileApp will degrade gracefully without compromising security. Among the many actions that might create extreme conditions are: (1) running several mobile apps on the same device, (2) infecting system software with viruses or malware, (3) attempting to take over a device and use it to spread spam, (4) forcing the mobile app to process inordinately large numbers of transactions, and (5) storing inordinately large quantities of data on the device. As these conditions are encountered, the MobileApp is checked to ensure that resource-intensive services (e.g., streaming media) are handled properly.

21.9 实时测试

21.9 Real-Time Testing

许多移动和实时应用程序的时间依赖性、异步特性为测试组合添加了一个新的且可能困难的元素——时间。测试用例设计者不仅必须考虑传统的测试用例,还必须考虑事件处理(即中断处理)、数据的时序以及处理数据的任务(进程)的并行性。在许多情况下,当实时系统处于一种状态时提供的测试数据将导致正确的处理,而当系统处于不同状态时提供的相同数据可能会导致错误。此外,实时软件与其硬件环境之间存在的密切关系也会导致测试问题。软件测试必须考虑硬件故障对软件处理的影响。此类故障极难真实模拟。

The time-dependent, asynchronous nature of many mobile and real-time applications adds a new and potentially difficult element to the testing mix—time. Not only does the test-case designer have to consider conventional test cases but also event handling (i.e., interrupt processing), the timing of the data, and the parallelism of the tasks (processes) that handle the data. In many situations, test data provided when a real-time system is in one state will result in proper processing, while the same data provided when the system is in a different state may lead to error. In addition, the intimate relationship that exists between real-time software and its hardware environment can also cause testing problems. Software tests must consider the impact of hardware faults on software processing. Such faults can be extremely difficult to simulate realistically.

许多 MobileApp 开发人员主张在野外进行测试,或者使用 MobileApp 资源的生产发布版本在用户的本机环境中进行测试 [Soa11]。野外测试旨在灵活地响应移动应用程序的发展变化 [Ute12]。第427页

Many MobileApp developers advocate testing in the wild, or testing in the users’ native environments with the production release versions of the MobileApp resources [Soa11]. Testing in the wild is designed to be agile and respond to changes as the MobileApp evolves [Ute12].Page 427

野外测试的一些特征包括不利且不可预测的环境、过时的浏览器和插件、独特的硬件以及不完善的连接(Wi-Fi 和移动运营商)。为了反映现实世界的情况,测试人员的人口统计特征应与目标用户及其设备的人口统计特征相匹配。此外,您还应该包括涉及少量用户、不太流行的浏览器以及各种移动设备的用例。野外测试总是有些不可预测,测试计划必须随着测试的进展进行调整。为了获得更多信息,Rooksby 和他的同事已经确定了成功的野外测试策略中存在的主题 [Roo09]。

Some of the characteristics of testing in the wild include adverse and unpredictable environments, outdated browsers and plug-ins, unique hardware, and imperfect connectivity (both Wi-Fi and mobile carrier). To mirror real-world conditions, the demographic characteristics of testers should match those of targeted users, as well as those of their devices. In addition, you should include use cases involving small numbers of users, less-popular browsers, as well as a diverse set of mobile devices. Testing in the wild is always somewhat unpredictable, and test plans must be adapted as testing progresses. For further information, Rooksby and his colleagues have identified themes that are present in successful strategies for testing in the wild [Roo09].

由于移动应用程序通常是为多种设备开发的,并且设计用于许多不同的环境和位置,因此加权设备平台矩阵(WDPM) 有助于确保测试覆盖范围包括移动设备和环境变量的每种组合。WDPM 还可用于帮助确定设备/上下文组合的优先级,以便首先测试最重要的。

Because MobileApps are often developed for multiple devices and designed to be used in many different contexts and locations, a weighted device platform matrix (WDPM) helps ensure that test coverage includes each combination of mobile device and context variables. The WDPM can also be used to help prioritize the device/context combinations so that the most important are tested first.

为多种设备和操作系统构建 WDPM(表 21.1 )的步骤如下:(1) 将重要的操作系统变体列为矩阵列标签,(2) 将目标设备列为矩阵行标签,(3) 分配排名(例如,0 到 10)以指示每个操作系统和每个设备的相对重要性,以及 (4) 计算每对排名的乘积并将每个乘积输入为矩阵中的单元格条目(对于组合使用 NA)那些不可用)。

The steps to build the WDPM (Table 21.1) for several devices and operating systems are: (1) list the important operating system variants as the matrix column labels, (2) list the targeted devices as the matrix row labels, (3) assign a ranking (e.g., 0 to 10) to indicate the relative importance of each operating system and each device, and (4) compute the product of each pair of rankings and enter each product as the cell entry in the matrix (use NA for combinations that are not available).

应调整测试工作,以便对于所考虑的每个上下文变量,具有最高评级的设备/平台组合受到最多关注。5表 21.1中,Device4OS3的评级最高,将在测试期间受到高度优先关注。

Testing effort should be adjusted so that the device/platform combinations with the highest ratings receive the most attention for each context variable under consideration.5 In Table 21.1, Device4 and OS3 have the highest rating and would receive high-priority attention during testing.

实际的移动设备具有由设备中提供的硬件和固件的组合造成的固有限制。如果潜在的设备平台范围很大,则执行 MobileApp 测试既昂贵又耗时。第428页

Actual mobile devices have inherent limitations precipitated by the combination of hardware and firmware delivered in the device. If the range of potential device platforms is large, it is expensive and time consuming to perform MobileApp testing.Page 428

移动设备的设计并未考虑到测试。有限的处理能力和存储容量可能不允许加载记录测试用例性能所需的诊断软件。仿真设备通常更易于管理,并且可以更轻松地获取测试数据。每个移动网络(全球有数百个)都使用自己独特的基础设施来支持移动网络。模拟器通常无法模拟网络服务的效果和时序,并且您可能看不到 MobileApp 在实际设备上运行时用户会遇到的问题。

Mobile devices are not designed with testing in mind. Limited processing power and storage capacity may not allow loading of the diagnostic software needed to record the test-case performance. Emulated devices are often easier to manage and allow easier acquisition of test data. Each mobile network (there are hundreds, worldwide) uses its own unique infrastructure to support the mobile Web. Emulators often cannot emulate the effects and timing of network services, and you may not see problems that users will have when the MobileApp runs on an actual device.

内部创建测试环境是一个昂贵且容易出错的过程。基于云的测试可以提供标准化的基础设施和预配置的软件映像,使 MobileApp 团队无需担心寻找服务器或购买自己的软件和测试工具许可证 [Goa14]。云服务提供商使测试人员能够访问可扩展、随时可用的虚拟实验室,其中包含操作系统库、测试和执行管理工具以及创建紧密反映现实世界的测试环境所需的存储[Tao17]。

Creating test environments in-house is an expensive and error-prone process. Cloud-based testing can offer a standardized infrastructure and preconfigured software images, freeing the MobileApp team from the need to worry about finding servers or purchasing their own licenses for software and testing tools [Goa14]. Cloud service providers give testers access to scalable, ready-to-use virtual laboratories with a library of operating systems, test and execution management tools, and storage necessary for creating a test environment that closely mirrors the real world [Tao17].

基于云的测试并非没有潜在的问题:缺乏标准、潜在的安全问题、数据位置和完整性问题、不完整的基础设施支持、服务使用不当以及性能问题只是使用云的开发团队面临的一些常见挑战。云方法。

Cloud-based testing is not without potential problems: lack of standards, potential security issues, data location and integrity issues, incomplete infrastructure support, improper usages of services, and performance issues are only some of the common challenges that face development teams that use the cloud approach.

最后,监控与在移动设备上使用 MobileApp 相关的功耗非常重要。从移动设备传输信息比监控网络信号消耗更多的电量。处理流媒体比加载网页或发送文本消息消耗更多的电量。准确评估功耗必须在实际设备上和在野外实时完成。

Last, it is important to monitor power consumption specifically associated with the use of the MobileApp on a mobile device. Transmitting information from mobile devices consumes more power than monitoring a network for a signal. Processing streaming media consumes more power than loading a Web page or sending a text message. Assessing power consumption accurately must be done in real time on the actual device and in the wild.

21.10 测试人工智能系统

21.10 Testing AI Systems

正如我们在第 13 章中讨论的那样,移动用户期望移动应用、VR 系统和视频游戏等产品具有情境感知能力。软件产品是否对用户环境做出反应 [Abd16]、根据过去的用户行为自动调整用户界面 [Par15],或者在游戏情况下提供逼真的非玩家角色 (NPC) [Ste16]、人工智能 (AI)涉及技术。这些技术通常会用到机器学习、数据挖掘、统计、启发式编程或基于规则的系统等,这些都超出了本书的范围。测试这些系统时存在几个常见问题,可以使用我们讨论的技术来解决。

As we discussed in Chapter 13, mobile users expect products like MobileApps, VR systems, and video games to be context aware. Whether the software product is reacting to the user’s environment [Abd16], automatically adapting the user interface based on past user behaviors [Par15], or providing a realistic nonplaying character (NPC) in a game situation [Ste16], artificial intelligence (AI) techniques are involved. Often these techniques make use of things like machine learning, data mining, statistics, heuristic programming, or rule-based systems that are outside the scope of this book. There are several problems common to testing these systems that can be addressed with the techniques we have discussed.

人工智能技术利用从人类专家那里获得的信息或从保存在某种数据存储中的大量观察中总结出来的信息。如果软件产品要具有上下文感知或自适应能力,则需要以某种方式组织这些数据,以便可以有效地访问和更新它们。利用这些数据来辅助软件中决策的启发式通常由人类在用例或从统计数据分析获得的公式中描述。这些系统难以测试的部分原因是软件需要考虑大量的数据交互,但其发生却很难预测。软件工程师通常需要依靠仿真和基于模型的技术来测试人工智能系统。第429页

AI techniques make use of information that has been obtained from human experts or summarized from large numbers of observations saved in a data store of some kind. These data need to be organized in some way so that they can be accessed and updated efficiently if the software product is to be context aware or self-adaptive. The heuristics for making use of these data to assist decision making in the software are usually described by humans in use cases or formulas obtained from statistical data analysis. Part of what makes these systems hard to test is the large number of data interactions that need to be accounted for by the software, but whose occurrence is hard to predict. Software engineers often need to rely on simulation and model-based techniques to test AI systems.Page 429

21.10.1 静态和动态测试

21.10.1 Static and Dynamic Testing

静态测试是一种软件验证技术,侧重于审查而不是可执行测试。重要的是要确保人类专家(了解应用领域的利益相关者)同意开发人员表示信息及其在人工智能系统中的使用的方式。与所有软件验证技术一样,确保程序代码代表人工智能规范非常重要,这意味着用例输入和输出之间的映射反映在代码中。

Static testing is a software verification technique that focuses on review rather than executable testing. It is important to ensure that human experts (stakeholders who understand the application domain) agree with the ways in which the developers have represented the information and its use in the AI system. Like all software verification techniques, it is important to ensure that the program code represents the AI specifications, which means mapping between use case inputs and outputs is reflected in the code.

人工智能系统的动态测试是一种通过测试用例来测试源代码的验证技术。目的是表明人工智能系统符合人类专家指定的行为。在知识发现或数据挖掘的情况下,该程序可能旨在发现人类专家未知的新关系。人类专家必须在将这些新关系用于安全关键软件产品之前验证它们[Abd16] [Par15]。

Dynamic testing for AI systems is a validation technique that exercises the source code with test cases. The intent is to show that the AI system conforms to the behaviors specified by the human experts. In the case of knowledge discovery or data mining, the program may have been designed to discover new relationships unknown to human experts. Human experts must validate these new relationships before they are used in safety-critical software products [Abd16] [Par15].

第 21.9 节中讨论的许多实时测试问题适用于人工智能系统的动态测试。即使使用自动生成的模拟测试用例,也不可能测试软件在野外遇到的每种事件组合。通常希望建立一种机制,允许用户指定何时对程序做出的决策不满意,并收集有关程序状态的信息,以便开发人员将来采取纠正措施。

Many of the real-time testing issues discussed in Section 21.9 apply in dynamic testing of AI systems. Even if automatically generated simulated test cases are used, it is not possible to test every combination of events the software will encounter in the wild. It is often desirable to build in mechanisms to allow the users to specify when they are not happy with the decisions made by the program and collect information on the program state for future corrective action by developers.

21.10.2 基于模型的测试

21.10.2 Model-Based Testing

基于模型的测试(MBT) 是一种黑盒测试技术,它使用需求模型(特别是用户故事)中包含的信息作为生成测试用例的基础 [DAC03]。在许多情况下,基于模型的测试技术使用 UML 状态图等形式主义(行为模型的一个元素(第 8 章))作为测试用例设计的基础。6 MBT 技术需要五个步骤:

Model-based testing (MBT) is a black-box testing technique that uses information contained in the requirements model (in particular the user stories) as the basis for the generation of test cases [DAC03]. In many cases, the model-based testing technique uses formalism like UML state diagrams, an element of the behavioral model (Chapter 8), as the basis for the design of test cases.6 The MBT technique requires five steps:

  1. 分析软件的现有行为模型,或创建一个。回想一下,行为模型表明软件将如何响应外部事件或刺激。要创建模型,您应该执行第 8 章中讨论的步骤:(1) 评估所有用例以充分理解系统内的交互序列,(2) 识别驱动交互序列的事件并了解这些事件如何与系统相关(3) 为每个用例创建一个序列,(4) 为系统构建 UML 状态图(例如,参见图 8.8)以及 (5) 检查行为模型以验证准确性和一致性。

  2. Analyze an existing behavioral model for the software, or create one. Recall that a behavioral model indicates how software will respond to external events or stimuli. To create the model, you should perform the steps discussed in Chapter 8: (1) evaluate all use cases to fully understand the sequence of interaction within the system, (2) identify events that drive the interaction sequence and understand how these events relate to specific objects, (3) create a sequence for each use case, (4) build a UML state diagram for the system (e.g., see Figure 8.8), and (5) review the behavioral model to verify accuracy and consistency.

  3. 遍历行为模型并指定将强制软件从一个状态转换到另一个状态的输入。输入将触发导致转换发生的事件。

  4. Traverse the behavioral model and specify the inputs that will force the software to make the transition from state to state. The inputs will trigger events that will cause the transition to occur.

  5. 查看行为模型,并记下软件从一个状态转换到另一个状态时的预期输出。回想一下,每个状态转换都是由事件触发的,并且作为转换的结果,某些函数被调用并创建输出。对于您在步骤 2 中指定的每组输入(测试用例),请指定预期输出,因为它们在行为模型中具有特征。第430页

  6. Review the behavioral model, and note the expected outputs as the software makes the transition from state to state. Recall that each state transition is triggered by an event and that as a consequence of the transition some function is invoked and outputs are created. For each set of inputs (test cases) you specified in step 2, specify the expected outputs as they are characterized in the behavioral model.Page 430

  7. 执行测试用例。测试用例可以手动执行,也可以创建测试脚本以供自动化测试工具使用。

  8. Execute the test cases. Test cases can be executed manually, or a test script can be created for use by an automated testing tool.

  9. 比较实际结果和预期结果,并根据需要采取纠正措施。

  10. Compare actual and expected results and take corrective action as required.

MBT 有助于发现软件行为中的错误,因此,在测试事件驱动的应用程序(例如上下文感知移动应用程序)时非常有用。

MBT helps to uncover errors in software behavior, and as a consequence, it is extremely useful when testing event-driven applications such as context-aware MobileApps.

21.11 测试虚拟环境

21.11 Testing Virtual Environments

软件开发人员几乎不可能预见客户将如何实际使用程序。使用说明可能会被误解;可能会使用奇怪的输入动作组合;对于测试人员来说似乎很清楚的反馈对于现场用户来说可能是难以理解的。用户体验设计师非常清楚在原型设计过程的早期获得实际用户反馈的重要性,以避免创建用户不喜欢的软件。

It is virtually impossible for a software developer to foresee how the customer will actually use a program. Instructions for use may be misinterpreted; strange combinations of input actions may be used; feedback that seemed clear to the tester may be unintelligible to a user in the field. User experience designers are very aware of the importance of getting feedback from actual users early in the prototyping process to avoid creating software that users dislike.

验收测试是客户在接受开发商提供的软件之前进行的一系列特定测试,试图发现产品错误。验收测试由最终用户而不是软件工程师进行,范围可以从非正式的“试驾”到有计划和系统执行的一系列脚本测试。

Acceptance tests are a series of specific tests conducted by the customer in an attempt to uncover product errors before accepting the software from the developer. Conducted by the end user rather than software engineers, acceptance testing can range from an informal “test drive” to a planned and systematically executed series of scripted tests.

当为一个客户构建软件产品时,该人进行一系列操作来验证所有需求是合理的。如果软件是虚拟模拟或游戏,开发为供许多客户使用的产品,那么允许每个用户执行正式的验收测试是不切实际的。大多数软件产品构建者使用称为 alpha 和 beta 测试的流程来发现似乎只有最终用户才能发现的错误。

When a software product is built for one customer, it is reasonable for that person to conduct a series to validate all requirements. If software is a virtual simulation or game developed as a product to be used by many customers, it is impractical to allow each user to perform formal acceptance tests. Most software product builders use a process called alpha and beta testing to uncover errors that only end users seem able to find.

alpha测试由一组具有代表性的最终用户在开发人员的站点上进行。该软件在自然环境中使用,开发人员“监视”用户并记录错误和使用问题。Alpha 测试是在受控环境中进行的。

The alpha test is conducted at the developer’s site by a representative group of end users. The software is used in a natural setting with the developer “looking over the shoulder” of the users and recording errors and usage problems. Alpha tests are conducted in a controlled environment.

Beta 测试在一个或多个最终用户站点进行。与 alpha 测试不同,开发人员通常不在场。因此,Beta测试是软件在开发者无法控制的环境中“现场”应用。客户记录 Beta 测试期间遇到的所有问题(真实的或想象的)并定期报告。根据 Beta 测试期间报告的问题,开发人员进行修改,然后准备向整个客户群发布软件产品。

The beta test is conducted at one or more end-user sites. Unlike alpha testing, the developer generally is not present. Therefore, the beta test is a “live” application of the software in an environment that cannot be controlled by the developer. The customer records all problems (real or imagined) that are encountered during beta testing and reports these at regular intervals. As a result of problems reported during beta tests, the developer makes modifications and then prepares for release of the software product to the entire customer base.

21.11.1 可用性测试

21.11.1 Usability Testing

可用性测试评估用户与应用程序有效交互的程度以及应用程序引导用户操作、提供有意义的反馈并强制执行一致的交互方法的程度。可用性审查和测试不是专注于某些交互目标的语义,而是旨在确定应用程序界面使用户的生活变得轻松的程度。7第431页

Usability testing evaluates the degree to which users can interact effectively with the app and the degree to which the app guides users’ actions, provides meaningful feedback, and enforces a consistent interaction approach. Rather than focusing intently on the semantics of some interactive objective, usability reviews and tests are designed to determine the degree to which the app interface makes the user’s life easy.7Page 431

开发人员参与可用性测试的设计,但通常测试是由最终用户进行的。可用性测试可以在各种不同的抽象级别上进行:(1)可以评估特定接口机制(例如表单)的可用性,(2)完整虚拟接口(包括接口机制、数据对象)的可用性,以及相关功能)可以进行评估,或者(3)可以考虑整个虚拟世界应用程序的可用性。

Developers contribute to the design of usability tests, but in general the tests are conducted by end users. Usability testing can occur at a variety of different levels of abstraction: (1) the usability of a specific interface mechanism (e.g., a form) can be assessed, (2) the usability of a complete virtual interface (encompassing interface mechanisms, data objects, and related functions) can be evaluated, or (3) the usability of the complete virtual-world application can be considered.

可用性测试的第一步是确定一组可用性类别并为每个类别建立测试目标。以下测试类别和目标(以问题的形式编写)说明了这种方法:8

The first step in usability testing is to identify a set of usability categories and establish testing objectives for each category. The following test categories and objectives (written in the form of a question) illustrate this approach:8

  • 互动性。交互机制(例如,下拉菜单、按钮、小部件、输入)是否易于理解和使用?

  • Interactivity. Are interaction mechanisms (e.g., pull-down menus, buttons, widgets, inputs) easy to understand and use?

  • 布局。导航机制、内容和功能是否以允许用户快速找到的方式放置?

  • Layout. Are navigation mechanisms, content, and functions placed in a manner that allows the user to find them quickly?

  • 可读性。文字写得好且易于理解吗?9图形表示是否容易理解?

  • Readability. Is text well written and understandable?9 Are graphic representations easy to understand?

  • 美学。布局、颜色、字体和相关特征是否会带来易用性?用户对应用程序的外观和感觉“感到舒服”吗?

  • Aesthetics. Do layout, color, typeface, and related characteristics lead to ease of use? Do users “feel comfortable” with the look and feel of the app?

  • 显示特性。该应用程序是否充分利用了屏幕尺寸和分辨率?

  • Display characteristics. Does the app make optimal use of screen size and resolution?

  • 时间敏感性。重要的特性、功能和内容能否及时使用或获取?

  • Time sensitivity. Can important features, functions, and content be used or acquired in a timely manner?

  • 反馈。用户是否收到对其行为有意义的反馈?当系统消息显示时,用户的工作是否可以中断并恢复?

  • Feedback. Do users receive meaningful feedback to their actions? Is the user’s work interruptible and recoverable when a system message is displayed?

  • 个性化。该应用程序是否适合不同用户类别或个人用户的特定需求?

  • Personalization. Does the app tailor itself to the specific needs of different user categories or individual users?

  • 帮助。用户是否可以轻松访问帮助和其他支持选项?

  • Help. Is it easy for users to access help and other support options?

  • 可访问性。该应用程序是否可供残障人士使用?

  • Accessibility. Is the app accessible to people who have disabilities?

  • 值得信赖。用户是否能够控制个人信息的共享方式?该应用程序是否未经用户许可使用个人信息?

  • Trustworthiness. Are users able to control how personal information is shared? Does the app make use of personal information without user permission?

每个类别都设计了一系列测试。在某些情况下,“测试”可能是对应用程序屏幕显示的视觉审查。在其他情况下,可能会再次执行接口语义测试,但在这种情况下,可用性问题至关重要。第432页

A series of tests is designed within each of these categories. In some cases, the “test” may be a visual review of the app screen displays. In other cases interface semantics tests may be executed again, but in this instance usability concerns are paramount.Page 432

作为一个例子,我们考虑交互和界面机制的可用性评估。以下是可以审查和测试可用性的界面功能列表:动画、按钮、颜色、控制、图形、标签、菜单、消息、导航、选择机制、文本和 HUD 10(平视用户显示器) 。在评估每个功能时,进行测试的用户会对其进行定性评分。图 21.3显示了用户可以选择的一组可能的评估“等级”。这些等级分别应用于每个功能、整个应用程序屏幕显示或整个应用程序。

As an example, we consider usability assessment for interaction and interface mechanisms. The following is a list of interface features that might be reviewed and tested for usability: animations, buttons, color, control, graphics, labels, menus, messages, navigation, selection mechanisms, text, and HUDs10 (heads-up user displays). As each feature is assessed, it is graded on a qualitative scale by the users who are doing the testing. Figure 21.3 shows a possible set of assessment “grades” that can be selected by users. These grades are applied to each feature individually, to a complete app screen display, or to the app as a whole.

21.3可用性的定性 评估

Figure 21.3 Qualitative assessment of usability

21.11.2 辅助功能测试

21.11.2 Accessibility Testing

可访问性测试是验证所有人可以使用计算机系统的程度的过程,无论任何用户的特殊需要如何。最常考虑的计算机系统可访问性的特殊需求是:视觉、听觉、运动和认知障碍 [Zan18]。许多特殊需求随着人们年龄的增长而变化。作为一个专业,虚拟环境开发并没有很好地为访问系统提供丰富的图形界面,这些界面严重依赖于触摸交互[Dia14]。只要改用 Alexa® 或 Siri® 等语音激活个人助理,问题就会得到解决。想象一下,尝试在不使用所有这些感官的情况下操作您的智能手机:视觉、听觉、触觉或言语。第433页

Accessibility testing is the process of verifying the degree to which all people can use a computer system regardless of any user’s special need. The special needs most commonly considered for computer system accessibility are: visual, hearing, movement, and cognitive impairments [Zan18]. Many of these special needs evolve as people get older. As a profession, virtual environment development has not done a good job of providing access systems with rich graphical interfaces that rely heavily on touch interactions [Dia14]. The problems merely shift with a switch to voice-activated personal assistants like Alexa® or Siri®. Just imagine trying to operate your smartphone without using all these senses: sight, hearing, touch, or speech.Page 433

我们在第 13 章中讨论了设计可访问软件产品的指南11。有效的设计策略应确保与用户的所有重要交互都使用多个信息渠道呈现。[Zan18] [Dia14] 是可访问性测试重点领域的几个示例:

We discussed guidelines11 for designing accessible software products in Chapter 13. An effective design strategy should ensure that all important interactions with the user be presented using more than one information channel. A few examples of the areas of focus for accessibility testing follow [Zan18] [Dia14]:

  • 确保所有非文本屏幕对象也由基于文本的描述表示。

  • Ensure that all nontext screen objects are also represented by a text-based description.

  • 验证颜色不仅仅用于向用户传达信息。

  • Verify that color is not used exclusively to convey information to the user.

  • 证明高对比度和放大倍数选项可供老年人或视力障碍用户使用。

  • Demonstrate that high contrast and magnification options are available for elderly or visually challenged users.

  • 确保已实施语音输入替代方案,以适应可能无法操作键盘、小键盘或鼠标的用户。

  • Ensure that speech input alternatives have been implemented to accommodate users that may not be able to manipulate a keyboard, keypad, or mouse.

  • 证明避免闪烁、滚动或自动内容更新,以适应有阅读困难的用户。

  • Demonstrate that blinking, scrolling, or auto content updating is avoided to accommodate users with reading difficulties.

基于云的移动软件很可能会主宰用户日常需要完成的许多事情(例如银行业务、报税、餐厅预订、旅行计划),因此,需要对于可访问的软件产品只会增长。除了专家评审和评估可访问性的自动化工具之外,全面的可访问性测试策略将有助于确保每个用户,无论他们面临什么挑战,都能得到满足。

It is likely that mobile, cloud-based software will come to dominate many things that users need to accomplish on a day-to-day basis (e.g., banking, tax preparation, restaurant reservations, trip planning) and as a consequence, the need for accessible software products will only grow. Along with expert review and automated tools to assess accessibility, a thorough accessibility testing strategy will help to ensure that every user, no matter their challenges, will be accommodated.

21.11.3 可玩性测试

21.11.3 Playability Testing

可玩性是指游戏或模拟玩起来有趣且可供用户/玩家使用的程度,最初被视为视频游戏开发的一部分。游戏的可玩性受到游戏质量的影响:可用性、故事情节、策略、机制、真实感、图形和声音。随着虚拟/增强现实模拟的出现,其目的是提供娱乐或学习机会(例如,模拟故障排除),使用可玩性测试作为 MobileApp 创建的虚拟环境可用性测试的一部分是有意义的 [Vel16] 。

Playability is the degree to which a game or simulation is fun to play and usable by the user/player and was originally conceived as part of the development of video games. Game playability is affected by the quality of the game: usability, storyline, strategy, mechanics, realism, graphics, and sound. With the advent of virtual/augmented reality simulations whose intention is to provide entertainment or learning opportunities (e.g., such as simulated troubleshooting), it makes sense to use playability testing as part of the usability testing for a virtual environment created by MobileApp [Vel16].

专家评审可以用作可玩性测试的一部分,但除非专家用户是您的目标用户组,否则您可能无法获得使您的移动应用程序在市场上取得成功所需的反馈。专家评审应辅之以由最终用户代表进行的可玩性测试,就像您可能对测试版或验收测试所做的那样。在典型的游戏测试中,可能会向用户提供有关使用应用程序的一般说明,然后开发人员会退后一步,观察玩家不间断地使用游戏。完成游戏测试后,玩家可能会被要求完成一份体验调查 [Hus15]。

Expert review can be used as part of the playability testing, but unless expert users are your target user group you may not get the feedback you need to have your MobileApp succeed in the marketplace. Expert review should be supplemented by playability tests conducted by representative end users, as you might do for a beta or acceptance test. In a typical play test, the user might be given general instructions on using the app and the developers would then step back and observe players use of the game without interruption. The players may be asked to complete a survey on their experience once they are done with the play test [Hus15].

第434页开发人员可能会记录游戏过程或只是记录他们所观察到的内容。开发人员正在寻找游戏会话中玩家不知道下一步该做什么的地方(这通常以玩家的操作突然停止为标志)。开发人员应注意此事件发生时玩家在应用程序工作流程中的位置。当游戏测试结束时,开发人员可能会讨论玩家卡住的原因以及玩家如何摆脱卡住(她确实做到了)。这表明可玩性测试也可能有助于评估虚拟环境的可访问性。

Page 434The developers might record the play session or simply take notes on what they observe. The developers are looking for places in the play session where the player does not know what to do next (this is usually marked by a sudden halt in the player’s actions). Developers should note where the player is in the app work flow when this event happens. When the play test has ended, the developers might discuss why the player got stuck and how the player got herself unstuck (it she did). This suggests that playability testing might be helpful in assessing the accessibility of a virtual environment as well.

21.12 测试文档和帮助工具

21.12 Testing Documentation and Help Facilities

术语“可用性测试”让人联想到准备运行计算机程序及其操作的数据的大量测试用例。但是,帮助工具或在线程序文档中的错误对于程序的接受度可能与数据或源代码中的错误一样具有破坏性。没有什么比严格遵循用户指南或帮助设施却得到与文档预测不一致的结果或行为更令人沮丧的了。正是由于这个原因,文档测试应该成为每个软件测试计划的重要组成部分。

The term usability testing conjures up images of large numbers of test cases prepared to exercise computer programs and the data that they manipulate. But errors in help facilities or online program documentation can be as devastating to the acceptance of the program as errors in data or source code. Nothing is more frustrating than following a user guide or help facility exactly and getting results or behaviors that do not coincide with those predicted by the documentation. It is for this reason that documentation testing should be an important part of every software test plan.

文档测试可以分两个阶段进行。第一阶段是技术审查(第 16 章),检查文档的编辑清晰度。第二阶段是实时测试,将文档与实际程序结合使用。

Documentation testing can be approached in two phases. The first phase, technical review (Chapter 16), examines the document for editorial clarity. The second phase, live test, uses the documentation in conjunction with the actual program.

令人惊讶的是,可以使用类似于前面讨论的许多黑盒测试方法的技术来进行文档的实时测试。可以使用基于图的测试来描述程序的使用情况;等价划分和边界值分析可用于定义各种输入类别和相关交互。MBT 可用于确保记录的行为与实际行为一致。然后通过文档跟踪程序的使用情况。

Surprisingly, a live test for documentation can be approached using techniques that are analogous to many of the black-box testing methods discussed earlier. Graph-based testing can be used to describe the use of the program; equivalence partitioning and boundary value analysis can be used to define various classes of input and associated interactions. MBT can be used to ensure that documented behavior and actual behavior coincide. Program usage is then tracked through the documentation.

第435页

Page 435

21.13 总结

21.13 Summary

移动应用程序测试的目标是测试移动应用程序软件质量的各个方面,目的是发现错误或发现可能导致质量故障的问题。测试重点关注质量要素,例如内容、功能、结构、可用性、上下文使用、可导航性、性能、电源管理、兼容性、互操作性、容量和安全性。它包含在设计移动应用程序时进行的审查和可用性评估,以及在实际设备上实施和部署移动应用程序后进行的测试。

The goal of MobileApp testing is to exercise each of the many dimensions of software quality for mobile applications with the intent of finding errors or uncovering issues that may lead to quality failures. Testing focuses on the quality elements such as content, function, structure, usability, use of context, navigability, performance, power management, compatibility, interoperability, capacity, and security. It incorporates reviews and usability assessments that occur as the MobileApp is designed, and tests that are conducted once the MobileApp has been implemented and deployed on an actual device.

移动应用程序测试策略通过最初检查内容、功能或导航的“单元”来执行每个质量维度。一旦单个单元得到验证,重点就会转移到对整个移动应用程序进行测试。为了实现这一点,许多测试都是从用户的角度出发,并由用例中包含的信息驱动。开发移动应用程序测试计划并确定测试步骤、工作产品(例如测试用例)以及测试结果评估机制。测试过程包含几种不同类型的测试。

The MobileApp testing strategy exercises each quality dimension by initially examining “units” of content, functionality, or navigation. Once individual units have been validated, the focus shifts to tests that exercise the MobileApp as a whole. To accomplish this, many tests are derived from the user’s perspective and are driven by information contained in use cases. A MobileApp test plan is developed and identifies testing steps, work products (e.g., test cases), and mechanisms for the evaluation of test results. The testing process encompasses several different types of testing.

内容测试(和评论)侧重于各种类别的内容。目的是检查影响向最终用户呈现内容的错误。需要检查内容是否存在移动设备限制带来的性能问题。界面测试运用定义移动应用程序提供的用户体验的交互机制。目的是发现当移动应用程序未考虑设备、用户或位置上下文时导致的错误。

Content testing (and reviews) focus on various categories of content. The intent is to examine errors that affect the presentation of the content to the end user. The content needs to be examined for performance issues imposed by the mobile device constraints. Interface testing exercises the interaction mechanisms that define the user experience provided by the MobileApp. The intent is to uncover errors that result when the MobileApp does not take device, user, or location context into account.

导航测试基于用例,作为建模活动的一部分而派生。测试用例旨在针对用于部署 MobileApp 的架构框架内的导航设计来测试每个使用场景。组件测试练习移动应用程序中的内容和功能单元。

Navigation testing is based on use cases, derived as part of the modeling activity. The test cases are designed to exercise each usage scenario against the navigation design within the architectural framework used to deploy the MobileApp. Component testing exercises content and functional units within the MobileApp.

性能测试包含一系列测试,旨在随着服务器端资源容量需求的增加评估 MobileApp 响应时间和可靠性。

Performance testing encompasses a series of tests that are designed to assess MobileApp response time and reliability as demands on server-side resource capacity increase.

安全测试包含一系列旨在利用 MobileApp 或其环境中的漏洞的测试。目的是发现设备操作环境或正在访问的 Web 服务中的安全漏洞。

Security testing incorporates a series of tests designed to exploit vulnerabilities in the MobileApp or its environment. The intent is to find security holes in either the device operating environment or the Web services being accessed.

最后,移动应用程序测试应该解决性能问题,例如功耗、处理速度、内存限制、从故障中恢复的能力以及连接问题。

Finally, MobileApp testing should address performance issues such as power usage, processing speed, memory limitations, ability to recover from failures, and connectivity issues.

导航测试将作为建模活动一部分派生的用例应用到测试用例的设计中,这些用例针对导航设计执行每个使用场景。测试导航机制以确保识别并纠正任何阻碍用例完成的错误。组件测试练习移动应用程序中的内容和功能单元。

Navigation testing applies use cases, derived as part of the modeling activity, in the design of test cases that exercise each usage scenario against the navigation design. Navigation mechanisms are tested to ensure that any errors impeding completion of a use case are identified and corrected. Component testing exercises content and functional units within the MobileApp.

问题与思考点

Problems and Points to Ponder

21.1。是否存在可以忽略实际设备上的 MobileApp 测试的情况?

21.1. Are there any situations in which MobileApp testing on actual devices can be disregarded?

21.2. 整体移动测试策略是从用户可见的元素开始,转向技术元素,这样说是否公平?该策略有例外吗?

21.2. Is it fair to say that the overall mobility testing strategy begins with user-visible elements and moves toward technology elements? Are there exceptions to this strategy?

第436页21.3。描述与应用程序的用户体验测试相关的步骤。

Page 43621.3. Describe the steps associated with user experience testing for an app.

21.4。安全测试的目的是什么?谁执行此测试活动?

21.4. What is the objective of security testing? Who performs this testing activity?

21.5。假设您正在开发一个移动应用程序来访问面向老年人的在线药房 ( YourCornerPharmacy.com )。药房提供典型的功能,但也为每个顾客维护一个数据库,以便它可以提供药物信息并警告潜在的药物相互作用。讨论此移动应用程序的任何特殊可用性或可访问性测试。

21.5. Assume that you are developing a MobileApp to access an online pharmacy (YourCornerPharmacy.com) that caters to senior citizens. The pharmacy provides typical functions but also maintains a database for each customer so that it can provide drug information and warn of potential drug interactions. Discuss any special usability or accessibility tests for this MobileApp.

21.6。假设您已经实现了一个为YourCornerPharmacy.com提供药物相互作用检查功能的 Web 服务(参见问题 21.5)。讨论必须在移动设备上进行的组件级测试类型,以确保 MobileApp 正确访问此功能。

21.6. Assume that you have implemented a Web service that provides a drug interaction–checking function for YourCornerPharmacy.com (see Problem 21.5). Discuss the types of component-level tests that would have to be conducted on the mobile device to ensure that the MobileApp accesses this function properly.

21.7。是否可以测试 MobileApp 在生产环境中可能遇到的所有配置?如果不是,您如何选择一组有意义的配置测试?

21.7. Is it possible to test every configuration that a MobileApp is likely to encounter in the production environment? If it is not, how do you select a meaningful set of configuration tests?

21.8。描述可能需要对 YourCornerPharmacy MobileApp 进行的安全测试(问题 21.5)。谁应该执行此测试?

21.8. Describe a security test that might need to be conducted for the YourCornerPharmacy MobileApp (Problem 21.5). Who should perform this test?

21.9。与接口机制相关的测试和解决接口语义的测试有什么区别?

21.9. What is the difference between testing that is associated with interface mechanisms and testing that addresses interface semantics?

21.10。导航语法测试和导航语义测试有什么区别?

21.10. What is the difference between testing for navigation syntax and navigation semantics?

1瘦客户端应用程序通常具有在移动设备上运行的用户界面软件(或 Web 浏览器软件),并使用网络接口连接基于 Internet 的应用程序或基于云的数据存储。

1 Thin-client apps typically have software for the user interface running on the mobile device (or Web browser software) and use a network interface to an Internet-based application or cloud-based data storage.

2当服务器请求转发到不存在的 URL 时。

2 When a server request is forwarded to a nonexistent URL.

3 众包是一种分布式问题解决模型,社区成员致力于解决向小组发布的问题。

3 Crowdsourcing is a distributed problem-solving model where community members work on solutions to problems posted to the group.

4贝尔等人的书。[Bel17]、Sullivan 和 Liu [Sul11] 以及 Cross [Cro07] 提供了有关该主题的有用信息。

4 Books by Bell et al. [Bel17], Sullivan and Liu [Sul11], and Cross [Cro07] provide useful information about the subject.

5 上下文变量是与当前连接或当前事务关联的变量,MobileApp 将使用这些变量来指导其可见用户行为。

5 Context variables are variables that are associated with either the current connection or the current transaction that the MobileApp will use to direct its visible-user behavior.

6当软件需求用决策表、语法或马尔可夫链表示时,也可以使用基于模型的测试 [DAC03]。

6 Model-based testing can also be used when software requirements are represented with decision tables, grammars, or Markov chains [DAC03].

7此处使用了“用户友好性”一词。当然,问题在于一个用户对“友好”界面的看法可能与另一个用户截然不同。

7 The term user-friendliness has been used in this context. The problem, of course, is that one user’s perception of a “friendly” interface may be radically different from another’s.

8有关可用性的更多信息,请参阅第 12 章。

8 For additional information on usability, see Chapter 12.

9 FOG 可读性指数和其他可用于提供可读性的定量评估。

9 The FOG Readability Index and others may be used to provide a quantitative assessment of readability.

10移动应用程序和游戏经常提供图形显示,其中包含用户状态、系统消息、导航日期和菜单选项,作为设备屏幕显示或 HUD 的一部分。

10 Mobile apps and games frequently provide graphical displays containing user status, system messages, navigation date, and menu choices as part of the device screen display or HUD.

11以下是美国司法部使用的软件可访问性清单示例:https://www.justice.gov/crt/software-accessibility-checklist。

11 Here is an example of a software accessibility checklist used by the United States Department of Justice: https://www.justice.gov/crt/software-accessibility-checklist.

第437页

Page 437

章节

chapter

22软件配置管理

22 Software Configuration Management

构建计算机软件时,更改是不可避免的,并且当您和软件团队的其他成员正在处理项目时,更改可能会导致混乱。如果在做出变更之前没有进行分析、在实施变更之前没有进行记录、没有向需要了解的人报告或以提高质量和减少错误的方式进行控制,就会出现混乱。Babich [Bab86] 提出了一种可以最大限度地减少混乱、提高生产力并减少错误数量的方法,他写道:“配置管理是识别、组织和控制对编程团队正在构建的软件进行修改的艺术。我们的目标是通过最大限度地减少错误来最大限度地提高生产力。”

Change is inevitable when computer software is built and can lead to confusion when you and other members of a software team are working on a project. Confusion arises when changes are not analyzed before they are made, recorded before they are implemented, reported to those with a need to know, or controlled in a manner that will improve quality and reduce error. Babich [Bab86] suggests an approach that will minimize confusion, improve productivity, and reduce the number of mistakes when he writes: “Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team. The goal is to maximize productivity by minimizing mistakes.”

第438页软件配置管理 (SCM) 是应用于整个软件流程的总括活动。典型的SCM工作流程如图22.1所示。由于变更可能随时发生,因此开发 SCM 活动的目的是 (1) 识别变更,(2) 控制变更,(3) 确保变更得到正确实施,以及 (4) 向可能感兴趣的其他人报告变更。

Page 438Software configuration management (SCM) is an umbrella activity that is applied throughout the software process. Typical SCM work flow is shown in Figure 22.1. Because change can occur at any time, SCM activities are developed to (1) identify change, (2) control change, (3) ensure that change is being properly implemented, and (4) report changes to others who may have an interest.

图22.1软件 配置管理工作流程

Figure 22.1 Software configuration management work flow

明确区分软件支持和软件配置管理非常重要。支持(第 27 章)是在软件交付给客户并投入运行后发生的一组软件工程活动。软件配置管理是一组跟踪和控制活动,这些活动在软件工程项目开始时启动,仅在软件停止运行时终止。

It is important to make a clear distinction between software support and software configuration management. Support (Chapter 27) is a set of software engineering activities that occur after software has been delivered to the customer and put into operation. Software configuration management is a set of tracking and control activities that are initiated when a software engineering project begins and terminates only when the software is taken out of operation.

软件工程的主要目标是提高适应变更的便利性,并减少必须进行变更时所花费的工作量。在本章中,我们讨论使您能够管理变革的具体活动。

A primary goal of software engineering is to improve the ease with which changes can be accommodated and reduce the amount of effort expended when changes must be made. In this chapter, we discuss the specific activities that enable you to manage change.

22.1 软件配置管理

22.1 Software Configuration Management

软件过程的输出是可分为三大类的信息:(1)计算机程序(源代码级和可执行形式),(2)描述计算机程序的工作产品(针对不同的利益相关者),以及( 3) 数据或内容(包含在程序内或程序外部)。在网页设计或游戏开发中,管理多媒体内容项的更改可能比管理软件或文档的更改要求更高。包含作为软件过程的一部分产生的所有信息的项目统称为软件配置

The output of the software process is information that may be divided into three broad categories: (1) computer programs (both source level and executable forms), (2) work products that describe the computer programs (targeted at various stakeholders), and (3) data or content (contained within the program or external to it). In Web design or game development, managing changes to the multimedia content items can be more demanding than managing the changes to the software or documentation. The items that comprise all information produced as part of the software process are collectively called a software configuration.

随着软件工程工作的进展,将创建软件配置项(SCI) 的层次结构(一种命名的信息元素,可以小到单个 UML 图,也可以大到完整的设计文档)。如果每个 SCI 都简单地引向其他 SCI,则不会造成什么混乱。不幸的是,另一个变量进入了这个过程——变化。变化可能随时因任何原因发生。事实上,系统工程第一定律[Ber80]指出:“无论处于系统生命周期的哪个阶段,系统都会发生变化,并且改变系统的愿望将在整个生命周期中持续存在。”第439页

As software engineering work progresses, a hierarchy of software configuration items (SCIs)—a named element of information that can be as small as a single UML diagram or as large as the complete design document—is created. If each SCI simply led to other SCIs, little confusion would result. Unfortunately, another variable enters the process—change. Change may occur at any time, for any reason. In fact, the first law of system engineering [Ber80] states: “No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.”Page 439

这些变化的根源是什么?这个问题的答案与变化本身一样多种多样。然而,变化有四个基本来源:

What is the origin of these changes? The answer to this question is as varied as the changes themselves. However, there are four fundamental sources of change:

  • 新的业务或市场条件决定了产品要求或业务规则的变化。

  • New business or market conditions dictate changes in product requirements or business rules.

  • 新的利益相关者需要对信息系统产生的数据、产品提供的功能或计算机系统提供的服务进行修改。

  • New stakeholder needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by a computer-based system.

  • 重组或业务增长或缩小规模会导致项目优先级或软件工程团队结构发生变化。

  • Reorganization or business growth or downsizing causes changes in project priorities or software engineering team structure.

  • 预算或进度限制导致系统或产品的重新定义。

  • Budgetary or scheduling constraints cause a redefinition of the system or product.

软件配置管理是一组为管理计算机软件整个生命周期中的变更而开发的活动。SCM 可以被视为一种应用于整个软件过程的软件质量保证活动。在接下来的部分中,我们将描述主要的 SCM 任务和帮助我们管理变更的重要概念。

Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software. SCM can be viewed as a software quality assurance activity that is applied throughout the software process. In the sections that follow, we describe major SCM tasks and important concepts that help us to manage change.

22.1.1 SCM 场景

22.1.1 An SCM Scenario

本节摘自[Dar01]。1

This section is extracted from [Dar01].1

典型的配置管理 (CM) 操作场景涉及多个利益相关者:负责软件组的项目经理、负责 CM 程序和策略的配置经理、负责开发和维护软件组的软件工程师。软件产品以及使用该产品的客户。在该场景中,假设该产品是一个小型产品,涉及约 15,000 行代码,由拥有 4 名开发人员的敏捷团队开发。(请注意,较小或较大团队的其他场景也是可能的,但本质上,每个项目都面临与 CM 相关的通用问题。)

A typical configuration management (CM) operational scenario involves several stakeholders: a project manager who is in charge of a software group, a configuration manager who is in charge of the CM procedures and policies, the software engineers who are responsible for developing and maintaining the software product, and the customer who uses the product. In the scenario, assume that the product is a small one involving about 15,000 lines of code being developed by an agile team with four developers. (Note that other scenarios of smaller or larger teams are possible, but, in essence, there are generic issues that each of these projects face concerning CM.)

在操作层面,场景涉及各种角色和任务。对于项目经理或团队负责人来说,目标是确保产品在一定的时间范围内开发出来。因此,经理监控开发进度并识别问题并做出反应。这是通过生成和分析有关软件系统状态的报告以及对系统进行审查来完成的。

At the operational level, the scenario involves various roles and tasks. For the project manager or team leader, the goal is to ensure that the product is developed within a certain time frame. Hence, the manager monitors the progress of development and recognizes and reacts to problems. This is done by generating and analyzing reports about the status of the software system and by performing reviews on the system.

配置经理(在小团队中可能是项目经理)的目标是确保遵循创建、更改和测试代码的过程和策略,以及使有关项目的信息易于访问。为了实施维持对代码更改的控制的技术,该经理引入了提出正式更改请求、与开发团队一起评估提议的更改以及确保产品所有者可以接受更改的机制。此外,管理器收集有关软件系统中的组件的统计数据,例如确定系统中哪些组件有问题的信息。第440页

The goals of the configuration manager (who on a small team may be the project manager) are to ensure that procedures and policies for creating, changing, and testing of code are followed, as well as to make information about the project accessible. To implement techniques for maintaining control over code changes, this manager introduces mechanisms for making official requests for changes, for evaluating proposed changes with the development team, and ensuring the changes are acceptable to the product owner. Also, the manager collects statistics about components in the software system, such as information determining which components in the system are problematic.Page 440

对于软件工程师来说,目标是有效地工作。必须有一种机制来确保对同一组件的同时更改得到正确跟踪、管理和执行。这意味着工程师在代码的创建和测试以及支持工作产品的生产中不会不必要地相互干扰。但与此同时,他们尝试有效地沟通和协调。具体来说,工程师使用帮助构建一致的软件产品的工具。他们通过相互通知所需的任务和已完成的任务来进行沟通和协调。通过合并文件,更改可以在彼此的工作中传播。存在机制可确保对于同时进行更改的组件,有某种方法可以解决冲突和合并更改。保留系统所有组件的演变历史以及包含更改原因的日志以及实际更改内容的记录。工程师有自己的工作空间来创建、更改、测试和集成代码。在某一点上,代码被制作成基线,进一步的开发将根据该基线继续进行,并为其他目标机器制作变体。

For the software engineers, the goal is to work effectively. There must be a mechanism to ensure that simultaneous changes to the same component are properly tracked, managed, and executed. This means engineers do not unnecessarily interfere with each other in the creation and testing of code and in the production of supporting work products. But, at the same time, they try to communicate and coordinate efficiently. Specifically, engineers use tools that help build a consistent software product. They communicate and coordinate by notifying one another about tasks required and tasks completed. Changes are propagated across each other’s work by merging files. Mechanisms exist to ensure that, for components that undergo simultaneous changes, there is some way of resolving conflicts and merging changes. A history is kept of the evolution of all components of the system along with a log with reasons for changes and a record of what actually changed. The engineers have their own workspace for creating, changing, testing, and integrating code. At a certain point, the code is made into a baseline from which further development continues and from which variants for other target machines are made.

客户使用该产品。由于产品受 CM 控制,因此客户遵循正式程序来请求更改并指出产品中的错误。

The customer uses the product. Because the product is under CM control, the customer follows formal procedures for requesting changes and for indicating bugs in the product.

理想情况下,此场景中使用的 CM 系统应该支持所有这些角色和任务;也就是说,角色决定了 CM 系统所需的功能。项目经理将CM视为一种审核机制;配置管理器将其视为控制、跟踪和决策机制;软件工程师将其视为一种更改、构建和访问控制机制;客户将其视为一种质量保证机制。

Ideally, a CM system used in this scenario should support all these roles and tasks; that is, the roles determine the functionality required of a CM system. The project manager sees CM as an auditing mechanism; the configuration manager sees it as a controlling, tracking, and policy-making mechanism; the software engineer sees it as a changing, building, and access control mechanism; and the customer sees it as a quality assurance mechanism.

22.1.2 配置管理系统的要素

22.1.2 Elements of a Configuration Management System

Susan Dart [Dar01] 在她关于软件配置管理的综合白皮书中指出了开发配置管理系统时应存在的四个重要元素:

In her comprehensive white paper on software configuration management, Susan Dart [Dar01] identifies four important elements that should exist when a configuration management system is developed:

  • 组成元素。耦合在文件管理系统(例如数据库)内的一组工具,能够访问和管理每个软件配置项。

  • Component elements. A set of tools coupled within a file management system (e.g., a database) that enables access to and management of each software configuration item.

  • 流程要素。一系列程序和任务,为涉及计算机软件的管理、工程和使用的所有支持者定义了变革管理(及相关活动)的有效方法。

  • Process elements. A collection of procedures and tasks that define an effective approach to change management (and related activities) for all constituencies involved in the management, engineering, and use of computer software.

  • 建筑元素。一组工具,通过确保组装了正确的经过验证的组件集(即正确的版本)来自动构建软件。

  • Construction elements. A set of tools that automate the construction of software by ensuring that the proper set of validated components (i.e., the correct version) have been assembled.

  • 人为因素。软件团队用来实施有效的 SCM 的一组工具和流程功能(包括其他 CM 元素)。

  • Human elements. A set of tools and process features (encompassing other CM elements) used by the software team to implement effective SCM.

这些元素(将在后面的部分中更详细地讨论)并不相互排斥。例如,随着软件过程的发展,组件元素与构造元素一起工作。流程元素指导许多与 SCM 相关的人类活动,因此也可能被视为人类元素。第441页

These elements (to be discussed in more detail in later sections) are not mutually exclusive. For example, component elements work in conjunction with construction elements as the software process evolves. Process elements guide many human activities that are related to SCM and might therefore be considered human elements as well.Page 441

22.1.3 基线

22.1.3 Baselines

变化是软件开发中不可避免的事实。客户想要修改需求。开发人员希望修改技术方法。管理者想要修改项目策略。为什么要进行所有这些修改?答案其实很简单。随着时间的推移,所有支持者都知道更多(关于他们需要什么,哪种方法最好,以及如何完成它并仍然赚钱)。大多数软件更改都是合理的,因此没有必要抱怨它们。相反,请确保您有适当的机制来处理它们。

Change is a fact of life in software development. Customers want to modify requirements. Developers want to modify the technical approach. Managers want to modify the project strategy. Why all this modification? The answer is really quite simple. As time passes, all constituencies know more (about what they need, which approach would be best, and how to get it done and still make money). Most software changes are justified, so there’s no point in complaining about them. Rather, be certain that you have mechanisms in place to handle them.

基线是一种软件配置管理概念,可帮助您控制更改,而不会严重阻碍合理的更改IEEE [IEE17] 将基线定义为:

A baseline is a software configuration management concept that helps you to control change without seriously impeding justifiable change. The IEEE [IEE17] defines a baseline as:

经过正式审查和同意的规范或产品,此后可作为进一步开发的基础,并且只能通过正式的变更控制程序进行更改。

A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

在软件配置项成为基线之前,可以快速且非正式地进行更改。然而,一旦建立了基线,就可以进行更改,但必须应用特定的正式程序来评估和验证每个更改。

Before a software configuration item becomes a baseline, change may be made quickly and informally. However, once a baseline is established, changes can be made, but a specific, formal procedure must be applied to evaluate and verify each change.

在软件工程的背景下,基线是软件开发的里程碑。基线是通过交付一个或多个软件配置项目来标记的,这些配置项目已作为技术审查的结果而获得批准(第 16 章)。例如,设计模型的元素已被记录和审查。错误被发现并纠正。一旦模型的所有部分都经过审查、纠正并获得批准,设计模型就成为基线。只有在每个项目都经过评估和批准后,才能对程序架构(记录在设计模型中)进行进一步的更改。尽管可以以任何详细程度定义基线,但最常见的软件基线如图 22.2所示。

In the context of software engineering, a baseline is a milestone in the development of software. A baseline is marked by the delivery of one or more software configuration items that have been approved as a consequence of a technical review (Chapter 16). For example, the elements of a design model have been documented and reviewed. Errors are found and corrected. Once all parts of the model have been reviewed, corrected, and then approved, the design model becomes a baseline. Further changes to the program architecture (documented in the design model) can be made only after each has been evaluated and approved. Although baselines can be defined at any level of detail, the most common software baselines are shown in Figure 22.2.

图22.2基线SCI 和项目数据库

Figure 22.2 Baselined SCIs and the project database

图 22.2还说明了导致基线的事件进展。软件工程任务产生一个或多个 SCI。SCI 经审核和批准后,它们将被放入项目数据库(也称为项目库软件存储库,并在第 22.5 节中讨论)。确保项目数据库维护在集中、受控的位置。当软件工程团队的成员想要对基线 SCI 进行修改时,会将其从项目数据库复制到工程师的私人工作区中。然而,只有遵循 SCM 控制(本章稍后讨论),才能修改提取的 SCI。图 22.2中的箭头说明了基线 SCI 的修改路径。

The progression of events that lead to a baseline is also illustrated in Figure 22.2. Software engineering tasks produce one or more SCIs. After SCIs are reviewed and approved, they are placed in a project database (also called a project library or software repository and discussed in Section 22.5). Be sure that the project database is maintained in a centralized, controlled location. When a member of a software engineering team wants to make a modification to a baselined SCI, it is copied from the project database into the engineer’s private workspace. However, this extracted SCI can be modified only if SCM controls (discussed later in this chapter) are followed. The arrows in Figure 22.2 illustrate the modification path for a baselined SCI.

22.1.4 软件配置项

22.1.4 Software Configuration Items

我们已经将软件配置项定义为作为软件工程过程的一部分创建的信息。在极端情况下,SCI 可以被视为大型规范的单个部分或大型测试套件中的一个测试用例。更现实地,SCI 是工作产品的全部或部分(例如,文档、整套测试用例、命名程序组件、多媒体内容资产或软件工具)。

We have already defined a software configuration item as information that is created as part of the software engineering process. In the extreme, an SCI could be considered to be a single section of a large specification or one test case in a large suite of tests. More realistically, an SCI is all or part of a work product (e.g., a document, an entire suite of test cases, a named program component, a multimedia content asset, or a software tool).

第442页实际上,SCI 被组织为形成配置对象,这些配置对象可以使用单个名称在项目数据库中编目。配置对象具有名称、属性,并通过关系“连接”到其他对象。参考图22.3,配置对象、DesignSpecification、DataModel、ComponentN、SourceCodeTestSpecification都是单独定义的。然而,每个对象都与其他对象相关,如箭头所示。弯曲的箭头表示组成关系。也就是说,DataModelComponentN是对象DesignSpecification 的一部分。双头直箭头表示相互关系。如果对SourceCode对象进行更改,则相互关系使您能够确定哪些其他对象(和 SCI)可能会受到影响。2

Page 442In reality, SCIs are organized to form configuration objects that may be cataloged in the project database with a single name. A configuration object has a name, attributes, and is “connected” to other objects by relationships. Referring to Figure 22.3, the configuration objects, DesignSpecification, DataModel, ComponentN, SourceCode, and TestSpecification are each defined separately. However, each of the objects is related to the others as shown by the arrows. A curved arrow indicates a compositional relation. That is, DataModel and ComponentN are part of the object DesignSpecification. A double-headed straight arrow indicates an interrelationship. If a change were made to the SourceCode object, the interrelationships enable you to determine what other objects (and SCIs) might be affected.2

图22.3 配置对象

Figure 22.3 Configuration objects

22.1.5 依赖关系和变更的管理

22.1.5 Management of Dependencies and Changes

我们在第 7.2.6 节中介绍了可追溯性的概念和可追溯性矩阵的使用。可追溯性矩阵是记录需求、架构决策(第 10.5 节)和缺陷原因(第 17.6 节)之间依赖关系的一种方法。在确定提议的变更的影响并指导选择用于回归测试的测试用例时,需要考虑这些依赖性(第 20.3 节)。de Sousa 和 Redmiles 写道,将依赖管理视为影响管理3有助于开发人员关注所做的更改如何影响他们的工作 [Sou08]。第443页

We introduced the concept of traceability and the use of traceability matrices in Section 7.2.6. The traceability matrix is one way to document dependencies among requirements, architectural decisions (Section 10.5), and defect causes (Section 17.6). These dependencies need to be considered when determining the impact of a proposed change and guiding the selection test cases that should be used for regression testing (Section 20.3). de Sousa and Redmiles write that viewing dependency management as impact management3 helps developers to focus on how changes made affect their work [Sou08].Page 443

影响分析侧重于组织行为和个人行为。影响管理涉及两个相辅相成的方面:(1)确保软件开发人员采用策略来最大限度地减少同事的行为对其自己工作的影响,以及(2)鼓励软件开发人员使用能够最大限度地减少自己的工作对其工作的影响的实践。他们的同事。值得注意的是,当开发人员试图尽量减少她的工作对他人的影响时,她也在减少其他人需要做的工作,以尽量减少她的工作对其他人的影响 [Sou08]。

Impact analysis focuses on organizational behavior as well as individual actions. Impact management involves two complementary aspects: (1) ensuring that software developers employ strategies to minimize the impact of their colleagues’ actions on their own work, and (2) encouraging software developers to use practices that minimize the impact of their own work on that of their colleagues. It is important to note that when a developer tries to minimize the impact of her work on others, she is also reducing the work others need to do to minimize the impact of her work on theirs [Sou08].

维护软件工作产品以确保开发人员了解 SCI 之间的依赖性非常重要。开发人员在将项目签入和签出 SCM 存储库以及进行批准的更改时必须建立纪律,如第 22.2 节中所述。

It is important to maintain software work products to ensure that developers are aware of the dependencies among the SCIs. Developers must establish discipline when checking items in and out of the SCM repository and when making approved changes, as discussed in Section 22.2.

22.2 SCM 存储库

22.2 The SCM Repository

SCM 存储库是一组机制和数据结构,允许软件团队以有效的方式管理变更。它通过确保数据完整性、共享和集成来提供现代数据库管理系统的明显功能。此外,SCM 存储库提供了软件工具集成的中心,是软件流程的核心,并且可以强制软件工程工作产品的统一结构和格式。

The SCM repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner. It provides the obvious functions of a modern database management system by ensuring data integrity, sharing, and integration. In addition, the SCM repository provides a hub for the integration of software tools, is central to the flow of the software process, and can enforce uniform structure and format for software engineering work products.

为了实现这些功能,存储库是根据元模型定义的。元模型决定了信息如何存储在存储库中、如何通过工具访问数据以及如何由软件工程师查看数据、如何维护数据安全性和完整性,以及如何轻松地扩展现有模型以适应新的需求。第444页

To achieve these capabilities, the repository is defined in terms of a meta-model. The meta-model determines how information is stored in the repository, how data can be accessed by tools and viewed by software engineers, how well data security and integrity can be maintained, and how easily the existing model can be extended to accommodate new needs.Page 444

22.2.1 一般特征和内容

22.2.1 General Features and Content

通过从两个角度观察可以最好地理解存储库的功能和内容:存储库中要存储什么以及存储库提供哪些特定服务。图 22.4显示了存储在存储库中的表示、文档和其他工作产品类型的详细分类。

The features and content of the repository are best understood by looking at it from two perspectives: what is to be stored in the repository and what specific services are provided by the repository. A detailed breakdown of types of representations, documents, and other work products that are stored in the repository is presented in Figure 22.4.

22.4 存储库的内容

Figure 22.4 Content of the repository

强大的存储库提供两种不同类别的服务:(1) 任何复杂的数据库管理系统可能期望的相同类型的服务;(2) 特定于软件工程环境的服务。

A robust repository provides two different classes of services: (1) the same types of services that might be expected from any sophisticated database management system and (2) services that are specific to the software engineering environment.

为软件工程团队服务的存储库还应该 (1) 集成或直接支持流程管理功能,(2) 支持管理 SCM 功能和存储库中维护的数据的特定规则,(3) 提供与其他软件的接口工程工具,(4) 容纳复杂数据对象(例如文本、图形、视频、音频)的存储。

A repository that serves a software engineering team should also (1) integrate with or directly support process management functions, (2) support specific rules that govern the SCM function and the data maintained within the repository, (3) provide an interface to other software engineering tools, and (4) accommodate storage of sophisticated data objects (e.g., text, graphics, video, audio).

22.2.2 单片机特性

22.2.2 SCM Features

为了支持 SCM,存储库必须能够维护与许多不同版本的软件相关的 SCI。更重要的是,它必须提供将这些 SCI 组装成特定于版本的配置的机制。存储库工具集需要提供对以下功能的支持。第445页

To support SCM, the repository must be capable of maintaining SCIs related to many different versions of the software. More important, it must provide the mechanisms for assembling these SCIs into a version-specific configuration. The repository tool set needs to provide support for the following features.Page 445

版本控制。随着项目的进展,将创建各个工作产品的许多版本(第 22.5.2 节)。存储库必须能够保存所有这些版本,以便能够有效管理产品版本,并允许开发人员在测试和调试期间返回到以前的版本。

Versioning. As a project progresses, many versions (Section 22.5.2) of individual work products will be created. The repository must be able to save all these versions to enable effective management of product releases and to permit developers to go back to previous versions during testing and debugging.

存储库必须能够控制各种对象类型,包括文本、图形、位图、复杂文档以及屏幕和报告定义、对象文件、测试数据和结果等独特对象。成熟的存储库以任意粒度级别跟踪对象的版本;例如,可以跟踪单个数据定义或一组模块。

The repository must be able to control a wide variety of object types, including text, graphics, bit maps, complex documents, and unique objects such as screen and report definitions, object files, test data, and results. A mature repository tracks versions of objects with arbitrary levels of granularity; for example, a single data definition or a cluster of modules can be tracked.

依赖性跟踪和变更管理。存储库管理存储在其中的数据元素之间的各种关系。其中包括企业实体和流程之间、应用程序设计各部分之间、设计组件和企业信息架构之间、设计元素和可交付成果之间的关系,等等。其中一些关系仅仅是关联,一些是依赖关系或强制关系。

Dependency Tracking and Change Management. The repository manages a wide variety of relationships among the data elements stored in it. These include relationships between enterprise entities and processes, among the parts of an application design, between design components and the enterprise information architecture, between design elements and deliverables, and so on. Some of these relationships are merely associations, and some are dependencies or mandatory relationships.

跟踪所有这些关系的能力对于存储在存储库中的信息的完整性以及基于它的可交付成果的生成至关重要,并且它是存储库概念对软件改进的最重要贡献之一发展过程。例如,如果 UML 类图被修改,存储库可以检测相关类、接口描述和代码组件是否也需要修改,并可以引起开发人员注意受影响的 SCI。

The ability to keep track of all these relationships is crucial to the integrity of the information stored in the repository and to the generation of deliverables based on it, and it is one of the most important contributions of the repository concept to the improvement of the software development process. For example, if a UML class diagram is modified, the repository can detect whether related classes, interface descriptions, and code components also require modification and can bring affected SCIs to the developer’s attention.

需求跟踪。这种特殊功能依赖于链接管理,并提供跟踪所有设计和施工组件以及由特定需求规范(前向跟踪)产生的可交付成果的能力。此外,它还能够识别哪个需求生成了任何给定的工作产品(向后跟踪)。

Requirements Tracing. This special function depends on link management and provides the ability to track all the design and construction components and deliverables that result from a specific requirements specification (forward tracing). In addition, it provides the ability to identify which requirement generated any given work product (backward tracing).

配置管理。配置管理工具跟踪代表特定项目里程碑或生产版本的一系列配置。

Configuration Management. A configuration management facility keeps track of a series of configurations representing specific project milestones or production releases.

审计跟踪。审计跟踪可建立有关何时、为何以及由谁进行更改的附加信息。有关更改源的信息可以作为存储库中特定对象的属性输入。每当修改设计元素时,存储库触发机制有助于提示开发人员或正在使用的工具启动审核信息(例如更改原因)的输入。

Audit Trails. An audit trail establishes additional information about when, why, and by whom changes are made. Information about the source of changes can be entered as attributes of specific objects in the repository. A repository trigger mechanism is helpful for prompting the developer or the tool that is being used to initiate entry of audit information (such as the reason for a change) whenever a design element is modified.

22.3 版本控制系统

22.3 Version Control Systems

版本控制结合了过程和工具来管理在软件过程中创建的配置对象的不同版本。版本控制系统实现或直接集成四个主要功能:(1)存储所有相关配置对象的项目数据库(存储库),(2)存储配置对象的所有版本(或启用任何版本)的版本管理功能使用与过去版本的差异来构建),(3) 一个make 工具,使您能够收集所有相关的配置对象并构建软件的特定版本。此外,版本控制和变更控制系统通常实现 (4)问题跟踪(也称为bug 跟踪)功能,使团队能够记录和跟踪与每个配置对象相关的所有未决问题的状态。第446页

Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process. A version control system implements or is directly integrated with four major capabilities: (1) a project database (repository) that stores all relevant configuration objects, (2) a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions), (3) a make facility that enables you to collect all relevant configuration objects and construct a specific version of the software. In addition, version control and change control systems often implement (4) an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.Page 446

许多版本控制系统建立了一个变更集——创建特定版本软件所需的所有变更(对某些基线配置)的集合。Dart [Dar91] 指出,更改集“捕获配置中所有文件的所有更改,以及更改的原因以及更改者和更改时间的详细信息。”

A number of version control systems establish a change set—a collection of all changes (to some baseline configuration) that are required to create a specific version of the software. Dart [Dar91] notes that a change set “captures all changes to all files in the configuration along with the reason for changes and details of who made the changes and when.”

可以为应用程序或系统标识许多命名的更改集。这使您能够通过指定必须应用于基线配置的更改集(按名称)来构建软件版本。为了实现这一点,应用了系统建模方法。系统模型包含:(1) 一个模板,其中包括组件层次结构和描述系统必须如何构建的组件的“构建顺序”,(2) 构建规则,以及 (3) 验证规则。4

A number of named change sets can be identified for an application or system. This enables you to construct a version of the software by specifying the change sets (by name) that must be applied to the baseline configuration. To accomplish this, a system modeling approach is applied. The system model contains: (1) a template that includes a component hierarchy and a “build order” for the components that describes how the system must be constructed, (2) construction rules, and (3) verification rules.4

多年来,人们提出了许多不同的自动化版本控制方法。5方法的主要区别在于用于构建系统的特定版本和变体的属性的复杂性以及构建过程的机制。

A number of different automated approaches to version control have been proposed over the years.5 The primary difference in approaches is the sophistication of the attributes that are used to construct specific versions and variants of a system and the mechanics of the process for construction.

22.4 持续集成

22.4 Continuous Integration

SCM 的最佳实践包括:(1) 保持代码变体数量较少,(2) 尽早且经常进行测试,(3) 尽早并经常进行集成,以及 (4) 使用工具来自动化测试、构建和代码集成。持续集成(CI) 对于遵循 DevOps 工作流程的敏捷开发人员非常重要(第 3.5.3 节)。CI 还通过确保每个更改都及时集成到项目源代码中、自动编译和测试来为 SCM 增加价值。CI 为开发团队提供了几个具体的优势 [Mol12]:

Best practices for SCM include: (1) keeping the number of code variants small, (2) test early and often, (3) integrate early and often, and (4) tool use to automate testing, building, and code integration. Continuous integration (CI) is important to agile developers following the DevOps workflow (Section 3.5.3). CI also adds value to SCM by ensuring that each change is promptly integrated into the project source code, compiled, and tested automatically. CI offers development teams several concrete advantages [Mol12]:

  • 加速反馈。当集成失败时立即通知开发人员可以在执行的更改数量很少的情况下进行修复。

  • Accelerated feedback. Notifying developers immediately when integration fails allows fixes to be made while the number of performed changes is small.

  • 质量提高。在必要时构建和集成软件可以让您对所开发产品的质量充满信心。第447页

  • Increased quality. Building and integrating software whenever necessary provides confidence into the quality of the developed product.Page 447

  • 降低风险。尽早集成组件可以避免长时间集成阶段的风险,因为设计故障可以尽早发现并修复。

  • Reduced risk. Integrating components early avoids risking a long integration phase because design failures are discovered and fixed early.

  • 改进了报告。提供附加信息(例如,代码分析指标)可以实现更准确的配置状态统计。

  • Improved reporting. Providing additional information (e.g., code analysis metrics) allows for more accurate configuration status accounting.

随着软件组织开始转向更敏捷的软件开发流程,CI 正在成为一项关键技术。CI 最好使用专门的工具来完成。6 CI 允许项目经理、质量保证经理和软件工程师通过减少缺陷逃逸到开发团队之外的可能性来提高软件质量。早期缺陷捕获总是可以通过在软件项目时间线的早期允许更便宜的修复来降低开发成本。

CI is becoming a key technology as software organizations begin their shift to more agile software development processes. CI is best done using specialized tools.6 CI allows project managers, quality assurance managers, and software engineers to improve software quality by reducing the likelihood of defects escaping outside the development team. Early defect capture always reduces the development costs by allowing cheaper fixes earlier in the software project time line.

22.5 变更管理流程

22.5 The Change Management Process

软件变更管理流程定义了一系列任务,这些任务有四个主要目标:(1) 识别共同定义软件配置的所有项目,(2) 管理对其中一个或多个项目的变更,(3) 促进构建应用程序的不同版本,以及 (4) 确保随着配置的不断发展而保持软件质量。

The software change management process defines a series of tasks that have four primary objectives: (1) to identify all items that collectively define the software configuration, (2) to manage changes to one or more of these items, (3) to facilitate the construction of different versions of an application, and (4) to ensure that software quality is maintained as the configuration evolves over time.

实现这些目标的过程不必是官僚和繁琐的,但它的特征必须能够使软件团队能够找到一组复杂问题的答案:

A process that achieves these objectives need not be bureaucratic and ponderous, but it must be characterized in a manner that enables a software team to develop answers to a set of complex questions:

  • 软件团队如何识别软件配置的离散元素?

  • How does a software team identify the discrete elements of a software configuration?

  • 组织如何以能够有效适应变更的方式管理程序(及其文档)的许多现有版本?

  • How does an organization manage the many existing versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently?

  • 组织如何控制软件发布给客户之前和之后的变更?

  • How does an organization control changes before and after software is released to a customer?

  • 组织如何评估变革的影响并有效管理影响?

  • How does an organization assess the impact of change and manage the impact effectively?

  • 谁负责批准请求的更改并对其进行排名?

  • Who has responsibility for approving and ranking requested changes?

  • 我们如何确保更改已正确进行?

  • How can we ensure that changes have been made properly?

  • 使用什么机制将所做的更改通知其他人?

  • What mechanism is used to apprise others of changes that are made?

这些问题导致了五个 SCM 任务的定义——识别、版本控制、变更控制、配置审核和报告——如图22.5所示。第448页

These questions lead to the definition of five SCM tasks—identification, version control, change control, configuration auditing, and reporting—illustrated in Figure 22.5.Page 448

图22.5 SCM 流程的各层

Figure 22.5 Layers of the SCM process

参考该图,SCM 任务可以被视为同心层。SCI 在其整个使用寿命期间通过这些层向外流动,最终成为应用程序或系统的一个或多个版本的软件配置的一部分。当 SCI 穿过一层时,每个 SCM 任务隐含的操作可能适用,也可能不适用。例如,当创建一个新的 SCI 时,必须对其进行标识。但是,如果 SCI 没有请求更改,则更改控制层不适用。SCI 被分配给软件的特定版本(版本控制机制发挥作用)。维护 SCI 的记录(其名称、创建日期、版本名称等)用于配置审核目的,并向需要了解的人员报告。在接下来的部分中,我们将更详细地研究每个 SCM 流程层。

Referring to the figure, SCM tasks can be viewed as concentric layers. SCIs flow outward through these layers throughout their useful life, ultimately becoming part of the software configuration of one or more versions of an application or system. As an SCI moves through a layer, the actions implied by each SCM task may or may not be applicable. For example, when a new SCI is created, it must be identified. However, if no changes are requested for the SCI, the change control layer does not apply. The SCI is assigned to a specific version of the software (version control mechanisms come into play). A record of the SCI (its name, creation date, version designation, etc.) is maintained for configuration auditing purposes and reported to those with a need to know. In the sections that follow, we examine each of these SCM process layers in more detail.

22.5.1 变更控制

22.5.1 Change Control

对于大型软件项目来说,不受控制的变更会迅速导致混乱。对于此类项目,变更控制结合了人工程序和自动化工具,提供了一种控制变更的机制。变更控制过程如图 22.6所示。提交并评估变更请求,以评估技术优点、潜在副作用、对其他配置对象和系统功能的总体影响以及变更的预计成本。评估结果以变更报告的形式呈现,供变更控制机构(CCA)使用,该机构是对变更的状态和优先级做出最终决定的个人或团体。为每个批准的变更生成工程变更单( ECO)。ECO 描述了要进行的变更、必须遵守的限制以及审查和审计的标准。第449页

For a large software project, uncontrolled change rapidly leads to chaos. For such projects, change control combines human procedures and automated tools to provide a mechanism for the control of change. The change control process is illustrated schematically in Figure 22.6. A change request is submitted and evaluated to assess technical merit, potential side effects, overall impact on other configuration objects and system functions, and the projected cost of the change. The results of the evaluation are presented as a change report, which is used by a change control authority (CCA)—a person or group that makes a final decision on the status and priority of the change. An engineering change order (ECO) is generated for each approved change. The ECO describes the change to be made, the constraints that must be respected, and the criteria for review and audit.Page 449

图22.6变更 控制流程

Figure 22.6 The change control process

第 450 页要更改的对象可以放置在由进行更改的软件工程师单独控制的目录中。一旦发生更改,版本控制系统(请参阅 CVS 侧栏)就会更新原始文件。作为替代方案,可以从项目数据库(存储库)“检出”要更改的对象,进行更改,并应用适当的 SQA 活动。然后,对象被“签入”到数据库中,并使用适当的版本控制机制(第 22.3 节)来创建软件的下一个版本。

Page 450The object(s) to be changed can be placed in a directory that is controlled solely by the software engineer making the change. A version control system (see the CVS sidebar) updates the original file once the change has been made. As an alternative, the object(s) to be changed can be “checked out” of the project database (repository), the change is made, and appropriate SQA activities are applied. The object(s) is (are) then “checked in” to the database, and appropriate version control mechanisms (Section 22.3) are used to create the next version of the software.

这些版本控制机制集成在变更控制流程中,实现了变更管理的两个重要元素——访问控制和同步控制。访问控制控制哪些软件工程师有权访问和修改特定的配置对象。同步控制有助于确保由两个不同的人执行的并行更改不会相互覆盖。

These version control mechanisms, integrated within the change control process, implement two important elements of change management—access control and synchronization control. Access control governs which software engineers have the authority to access and modify a particular configuration object. Synchronization control helps to ensure that parallel changes, performed by two different people, don’t overwrite one another.

您可能对图 22.6所示的变更控制流程描述所隐含的官僚主义程度感到不舒服。这种感觉并不少见。如果没有适当的保障措施,变更控制可能会阻碍进展并产生不必要的繁文缛节。大多数拥有变更控制机制(不幸的是,许多人没有)的软件开发人员都创建了多个控制层来帮助避免这里提到的问题。

You may feel uncomfortable with the level of bureaucracy implied by the change control process description shown in Figure 22.6. This feeling is not uncommon. Without proper safeguards, change control can retard progress and create unnecessary red tape. Most software developers who have change control mechanisms (unfortunately, many have none) have created a number of layers of control to help avoid the problems alluded to here.

在 SCI 成为基线之前,只需应用非正式的变更控制。相关配置对象 (SCI) 的开发人员可以根据项目和技术要求进行任何合理的更改(只要更改不会影响超出开发人员工作范围的更广泛的系统要求)。一旦对象经过技术审查并获得批准,就可以创建基线。7一旦 SCI 成为基线,就会实施项目级别的变更控制。现在,要进行更改,开发人员必须获得项目经理的批准(如果更改是“本地”),或者如果更改影响其他 SCI,则必须获得 CCA 的批准。在某些情况下,开发人员无需正式生成变更请求、变更报告和 ECO。但是,会对每个变更进行评估,并跟踪和审查所有变更。

Prior to an SCI becoming a baseline, only informal change control need be applied. The developer of the configuration object (SCI) in question may make whatever changes are justified by project and technical requirements (as long as changes do not affect broader system requirements that lie outside the developer’s scope of work). Once the object has undergone technical review and has been approved, a baseline can be created.7 Once an SCI becomes a baseline, project level change control is implemented. Now, to make a change, the developer must gain approval from the project manager (if the change is “local”) or from the CCA if the change affects other SCIs. In some cases, the developer dispenses with the formal generation of change requests, change reports, and ECOs. However, assessment of each change is conducted and all changes are tracked and reviewed.

当软件产品发布给客户时,就会建立正式的变更控制。图 22.6概述了正式的变更控制程序。

When the software product is released to customers, formal change control is instituted. The formal change control procedure has been outlined in Figure 22.6.

变更控制机构在第二层和第三层控制中发挥着积极作用。根据软件项目的规模和特点,CCA 可能由一个人(项目经理)或多个人(例如,来自软件、硬件、数据库工程、支持、营销的代表)组成。CCA 的作用是采取全球视野,即评估相关 SCI 之外的变化的影响。这一变化将如何影响硬件?这一变化将如何影响性能?这一变化将如何改变客户对产品的看法?变化将如何影响产品质量和可靠性?CCA 解决了这些问题和许多其他问题。第 451 页

The change control authority plays an active role in the second and third layers of control. Depending on the size and character of a software project, the CCA may be composed of one person—the project manager—or a number of people (e.g., representatives from software, hardware, database engineering, support, marketing). The role of the CCA is to take a global view, that is, to assess the impact of change beyond the SCI in question. How will the change affect hardware? How will the change affect performance? How will the change modify customers’ perception of the product? How will the change affect product quality and reliability? These and many other questions are addressed by the CCA.Page 451

22.5.2 影响管理

22.5.2 Impact Management

每次进行更改时都必须考虑软件工作产品相互依赖性的网络。影响管理包括正确理解这些相互依赖性并控制它们对其他 SCI(以及负责它们的人员)的影响所需的工作。

A web of software work product interdependencies must be considered every time a change is made. Impact management encompasses the work required to properly understand these interdependencies and control their effects on other SCIs (and the people who are responsible for them).

影响管理通过三个行动来完成[Sou08]。首先,影响网络识别可能影响软件更改或受软件更改影响的软件团队(和其他利益相关者)的成员。软件架构的清晰定义(第 10 章)对于创建影响力网络有很大帮助。接下来,前向影响管理评估您自己的更改对影响网络成员的影响,然后通知成员这些更改的影响。最后,后向影响管理检查其他团队成员所做的更改及其对您工作的影响,并纳入减轻影响的机制。第452页

Impact management is accomplished with three actions [Sou08]. First, an impact network identifies the members of a software team (and other stakeholders) who might effect or be affected by changes that are made to the software. A clear definition of the software architecture (Chapter 10) assists greatly in the creation of an impact network. Next, forward impact management assesses the impact of your own changes on the members of the impact network and then informs members of the impact of those changes. Finally, backward impact management examines changes that are made by other team members and their impact on your work and incorporates mechanisms to mitigate the impact.Page 452

22.5.3 配置审核

22.5.3 Configuration Audit

识别、版本控制和变更控制可帮助您在混乱且不稳定的情况下维持秩序。然而,即使是最成功的控制机制也只能在生成 ECO 之前跟踪变化。软件团队如何确保变更得到正确实施?答案有两个:(1)技术审查和(2)软件配置审核。

Identification, version control, and change control help you to maintain order in what would otherwise be a chaotic and fluid situation. However, even the most successful control mechanisms track a change only until an ECO is generated. How can a software team ensure that the change has been properly implemented? The answer is twofold: (1) technical reviews and (2) the software configuration audit.

技术审查(第16章)重点关注已修改的配置对象的技术正确性。审稿人评估 SCI 以确定与其他 SCI 的一致性、遗漏或潜在的副作用。除最微不足道的变更外,应对所有变更进行技术审查。

The technical review (Chapter 16) focuses on the technical correctness of the configuration object that has been modified. The reviewers assess the SCI to determine consistency with other SCIs, omissions, or potential side effects. A technical review should be conducted for all but the most trivial changes.

软件配置审核通过评估配置对象的特征来补充技术审核,这些特征在审核期间通常不会考虑。审计提出并回答以下问题:

A software configuration audit complements the technical review by assessing a configuration object for characteristics that are generally not considered during review. The audit asks and answers the following questions:

  1. ECO 中指定的变更是否已进行?是否纳入了任何其他修改?

  2. Has the change specified in the ECO been made? Have any additional modifications been incorporated?

  3. 是否进行了技术审查来评估技术正确性?

  4. Has a technical review been conducted to assess technical correctness?

  5. 是否遵循了软件流程,是否正确应用了软件工程标准?

  6. Has the software process been followed, and have software engineering standards been properly applied?

  7. SCI 中是否“突出”了这一变化?是否指定了更改日期和更改作者?配置对象的属性是否反映了变化?

  8. Has the change been “highlighted” in the SCI? Have the change date and change author been specified? Do the attributes of the configuration object reflect the change?

  9. 是否遵循了记录变更、记录变更和报告变更的 SCM 程序?

  10. Have SCM procedures for noting the change, recording it, and reporting it been followed?

  11. 所有相关的 SCI 是否都已正确更新?

  12. Have all related SCIs been properly updated?

在某些情况下,审计问题是作为技术审查的一部分提出的。然而,当SCM是一项正式活动时,配置审核由质量保证小组单独进行。此类正式配置审核还确保正确的 SCI(按版本)已合并到特定构建中,并且所有文档都是最新的并与已构建的版本一致。

In some cases, the audit questions are asked as part of a technical review. However, when SCM is a formal activity, the configuration audit is conducted separately by the quality assurance group. Such formal configuration audits also ensure that the correct SCIs (by version) have been incorporated into a specific build and that all documentation is up to date and consistent with the version that has been built.

22.5.4 状态报告

22.5.4 Status Reporting

配置状态报告(有时称为状态统计)是一项 SCM 任务,它回答以下问题: (1) 发生了什么?(2)谁干的?(3)什么时候发生的?(4)还有什么会受到影响?

Configuration status reporting (sometimes called status accounting) is an SCM task that answers the following questions: (1) What happened? (2) Who did it? (3) When did it happen? (4) What else will be affected?

配置状态报告(CSR)的信息流如图22.6所示。至少,为每个配置对象制定一个“需要了解”的列表并保持最新。进行更改时,请确保通知列表中的每个人。每次为 SCI 分配新的或更新的标识时,都会生成一个 CSR 条目。每次 CCA 批准变更(即发布 ECO)时,都会生成 CSR 条目。每次进行配置审核时,结果都会作为 CSR 任务的一部分进行报告。CSR 的输出可以放置在在线数据库或网站中,以便软件开发人员或支持人员可以按关键字类别访问变更信息。此外,定期生成企业社会责任报告,旨在让管理层和从业人员了解重要变化。

The flow of information for configuration status reporting (CSR) is illustrated in Figure 22.6. At the very least, develop a “need to know” list for every configuration object and keep it up to date. When a change is made, be sure that everyone on the list is notified. Each time an SCI is assigned new or updated identification, a CSR entry is made. Each time a change is approved by the CCA (i.e., an ECO is issued), a CSR entry is made. Each time a configuration audit is conducted, the results are reported as part of the CSR task. Output from CSR may be placed in an online database or website, so that software developers or support staff can access change information by keyword category. In addition, a CSR report is generated on a regular basis and is intended to keep management and practitioners apprised of important changes.

第453页

Page 453

22.6 移动性和敏捷变更管理

22.6 Mobility and Agile Change Management

在本书的前面,我们讨论了 WebApp 和 MobileApp 的特殊性质以及构建它们所需的专门方法8 。游戏开发人员面临着类似的挑战,所有敏捷开发团队也面临着类似的挑战。这些应用程序与传统软件的众多区别之一是变化的普遍性。

Earlier in this book, we discussed the special nature of WebApps and MobileApps and the specialized methods8 that are required to build them. Game developers face similar challenges, as do all agile development teams. Among the many characteristics that differentiate these applications from traditional software is the ubiquitous nature of change.

移动开发人员和游戏开发人员经常使用迭代、增量流程模型,该模型应用了源自敏捷软件开发的许多原则(第 4 章)。使用这种方法,工程团队通常会使用客户驱动的方法在很短的时间内开发增量。后续的增量会添加额外的内容和功能,并且每个增量都可能会实现一些更改,从而增强内容、更好的可用性、改进的美观、更好的导航、增强的性能和更强的安全性。因此,在应用程序和游戏开发的敏捷世界中,对变革的看法有些不同。

Mobile developers and game developers often use an iterative, incremental process model that applies many principles derived from agile software development (Chapter 4). Using this approach, an engineering team often develops an increment in a very short time period using a customer-driven approach. Subsequent increments add additional content and functionality, and each is likely to implement changes that lead to enhanced content, better usability, improved aesthetics, better navigation, enhanced performance, and stronger security. Therefore, in the agile world of app and game development, change is viewed somewhat differently.

如果您是构建应用程序或游戏的软件团队的成员,您必须拥抱变化。然而,典型的敏捷团队会避开所有看起来流程繁重、官僚主义和正式的事情。软件配置管理通常被认为(尽管不正确)具有这些特征。这种看似矛盾的解决方法不是拒绝 SCM 原则、实践和工具,而是通过塑造它们来满足移动项目的特殊需求。

If you’re a member of a software team that builds apps or games, you must embrace change. And yet, a typical agile team eschews all things that appear to be process-heavy, bureaucratic, and formal. Software configuration management is often viewed (albeit incorrectly) to have these characteristics. This seeming contradiction is remedied not by rejecting SCM principles, practices, and tools, but rather by molding them to meet the special needs of mobile projects.

22.6.1 电子变更控制

22.6.1 e-Change Control

对于 WebApp 和移动软件开发来说,与传统软件变更控制相关的工作流程(第 22.5.1 节)通常过于繁重。变更请求、变更报告和工程变更顺序顺序不太可能以许多游戏和应用程序开发项目可接受的敏捷方式实现。那么我们如何管理内容和功能请求的连续变更流呢?

The work flow associated with change control for conventional software (Section 22.5.1) is generally too ponderous for WebApp and mobile software development. It is unlikely that the change request, change report, and engineering change order sequence can be achieved in an agile manner that is acceptable for many game and app development projects. How then do we manage a continuous stream of changes requested for content and functionality?

为了在继续主导大部分游戏和移动开发的“代码即执行”理念中实施有效的变更管理,可以修改传统的变更控制流程。每个更改都应分为四类之一:

To implement effective change management within the “code and go” philosophy that continues to dominate much of game and mobile development, the conventional change control process can be modified. Each change should be categorized into one of four classes:

  • 第 1 类。纠正错误或增强本地内容或功能的内容或功能更改。

  • Class 1. A content or function change that corrects an error or enhances local content or functionality.

  • 2 类。对其他内容对象或功能组件有影响的内容或功能更改。

  • Class 2. A content or function change that has an impact on other content objects or functional components.

  • 第 3 类。对整个应用程序产生广泛影响的内容或功能更改(例如,功能的主要扩展、内容的显着增强或减少、导航所需的主要更改)。

  • Class 3. A content or function change that has a broad impact across an app (e.g., major extension of functionality, significant enhancement or reduction in content, major required changes in navigation).

  • 第 4 类。一类或多类用户会立即注意到的重大设计更改(例如,界面设计或导航方法的更改)。

  • Class 4. A major design change (e.g., a change in interface design or navigation approach) that will be immediately noticeable to one or more categories of user.

一旦请求的更改被分类,就可以根据图 22.7所示的Web 应用程序算法进行处理,但同样适用于应用程序和游戏。第454页

Once the requested change has been categorized, it can be processed according to the algorithm shown in Figure 22.7 for WebApps but is equally applicable for apps and games.Page 454

22.7 管理 WebApp 的更改

Figure 22.7 Managing changes for WebApps

第 455 页如图所示,1 类和 2 类变更被非正式地处理,并以敏捷的方式处理。对于 1 类变更,您将评估变更的影响,但不需要外部审查或文档。进行更改时,配置存储库工具将强制执行标准的签入和签出过程。对于 2 类更改,您应该检查更改对相关对象的影响(或要求负责这些对象的其他开发人员这样做)。如果无需对其他对象进行重大更改即可进行更改,则无需额外审查或记录即可进行修改。如果需要实质性改变,则需要进一步评估和规划。

Page 455Referring to the figure, class 1 and 2 changes are treated informally and are handled in an agile manner. For a class 1 change, you would evaluate the impact of the change, but no external review or documentation is required. As the change is made, standard check-in and check-out procedures are enforced by configuration repository tools. For class 2 changes, you should review the impact of the change on related objects (or ask other developers responsible for those objects to do so). If the change can be made without requiring significant changes to other objects, modification occurs without additional review or documentation. If substantive changes are required, further evaluation and planning are necessary.

3 类和 4 类变更也以敏捷的方式处理,但需要一些描述性文档和更正式的审核程序。变更描述(描述变更并提供变更影响的简要评估)是为 3 类变更制定的。该描述会分发给团队的所有成员,他们会对其进行审查,以更好地评估其影响。还为 4 类变更制定了变更描述,但在这种情况下,所有利益相关者都会进行审查。

Class 3 and 4 changes are also treated in an agile manner, but some descriptive documentation and more formal review procedures are required. A change description—describing the change and providing a brief assessment of the impact of the change—is developed for class 3 changes. The description is distributed to all members of the team who review it to better assess its impact. A change description is also developed for class 4 changes, but in this case all stakeholders conduct the review.

22.6.2 内容管理

22.6.2 Content Management

内容管理与配置管理相关,即内容管理系统 (CMS) 建立一个流程(由适当的工具支持),该流程获取现有内容(从广泛的应用程序和/或游戏配置对象中),将其构建为使其能够呈现给最终用户,然后提供给客户端环境进行显示。

Content management is related to configuration management in the sense that a content management system (CMS) establishes a process (supported by appropriate tools) that acquires existing content (from a broad array of app and/or game configuration objects), structures it in a way that enables it to be presented to an end user, and then provides it to the client-side environment for display.

内容管理系统最常见的用途发生在构建动态应用程序时。应用程序和游戏“即时”创建屏幕显示。也就是说,用户通常通过改变屏幕上显示的信息来执行软件响应的动作。用户操作可能会导致应用程序查询服务器端数据库;然后,它相应地格式化信息并将其呈现给用户。

The most common use of a content management system occurs when a dynamic application is built. Apps and games create screen displays “on the fly.” That is, the user typically performs an action that the software responds to by changing the information displayed on the screen. The user action may cause the app to query a server-side database; it then formats the information accordingly and presents it to the user.

例如,音乐商店(例如,Apple iTunes)提供数十万首曲目供销售。当用户请求音乐曲目时,会查询数据库,并且有关艺术家、CD(例如,其封面图像或图形)、音乐内容和样本音频的各种信息都会被下载并配置到标准内容模板中。生成的页面在服务器端构建并传递到客户端以供最终用户检查。WebApp 的通用表示如图 22.8所示。

For example, a music store (e.g., Apple iTunes) provides hundreds of thousands of tracks for sale. When a user requests a music track, a database is queried and a variety of information about the artist, the CD (e.g., its cover image or graphics), the musical content, and sample audio are all downloaded and configured into a standard content template. The resultant page is built on the server side and passed to the client side for examination by the end user. A generic representation for WebApps is shown in Figure 22.8.

图22.8内容 管理系统

Figure 22.8 Content management system

22.6.3 集成与发布

22.6.3 Integration and Publishing

内容管理系统对于编写 Web 服务以创建上下文感知的移动应用程序、在运行时更新游戏级场景以及构建动态网页非常有用。从最一般的意义上来说,CMS 通过调用三个集成子系统为最终用户“配置”内容:收集子系统、管理子系统和发布子系统 [Boi04]。

Content management systems are useful for composing Web services to create context-aware MobileApps and updating game-level scenes at run time, as well as building dynamic Web pages. In the most general sense, a CMS “configures” content for the end user by invoking three integrated subsystems: a collection subsystem, a management subsystem, and a publishing subsystem [Boi04].

集合子系统。内容源自内容开发者必须创建或获取的数据和信息。收集子系统包含创建和/或获取内容所需的所有操作,以及 (1) 将内容转换为可以用标记语言(例如 HTML、XML)表示的形式,以及(2) 将内容组织成可以在客户端有效显示的屏幕。第456页

The Collection Subsystem. Content is derived from data and information that must be created or acquired by a content developer. The collection subsystem encompasses all actions required to create and/or acquire content, and the technical functions that are necessary to (1) convert content into a form that can be represented by a mark-up language (e.g., HTML, XML), and (2) organize content into screens that can be displayed efficiently on the client side.Page 456

内容创建和获取(通常称为游戏创作关卡设计)通常与其他开发活动并行发生,并且通常由非技术内容开发人员进行。这项活动结合了创造力和研究的元素,并得到了工具的支持,这些工具使内容作者能够以可在应用程序或游戏中使用的标准化方式来描述内容。

Content creation and acquisition (often called authoring or level design for games) commonly occurs in parallel with other development activities and is often conducted by nontechnical content developers. This activity combines elements of creativity and research and is supported by tools that enable the content author to characterize content in a manner that can be standardized for use within the app or game.

内容一旦存在,就必须进行转换以符合 CMS 的要求。这意味着剥离原始内容中的任何不必要的信息(例如,冗余的图形表示),格式化内容以符合CMS的要求,并将结果映射到使其能够被管理和发布的信息结构中。

Once content exists, it must be converted to conform to the requirements of a CMS. This implies stripping raw content of any unnecessary information (e.g., redundant graphical representations), formatting the content to conform to the requirements of the CMS, and mapping the results into an information structure that will enable it to be managed and published.

管理子系统。一旦内容存在,就必须将其存储在存储库中,对其进行编目以供后续获取和使用,并进行标记以定义(1)当前状态(例如,内容对象是完整的还是正在开发中?),(2)内容的适当版本内容对象,以及(3)相关内容对象。配置管理是在该子系统内执行的。因此,管理子系统实现了一个包含以下元素的存储库:第 457 页

The Management Subsystem. Once content exists, it must be stored in a repository, cataloged for subsequent acquisition and use, and labeled to define (1) current status (e.g., is the content object complete or in development?), (2) the appropriate version of the content object, and (3) related content objects. Configuration management is performed within this subsystem. Therefore, the management subsystem implements a repository that encompasses the following elements:Page 457

  • 内容数据库。为存储所有内容对象而建立的信息结构。

  • Content database. The information structure that has been established to store all content objects.

  • 数据库功能。使 CMS 能够搜索特定内容对象(或对象类别)、存储和检索对象以及管理已为内容建立的文件结构的功能。

  • Database capabilities. Functions that enable the CMS to search for specific content objects (or categories of objects), store and retrieve objects, and manage the file structure that has been established for the content.

  • 配置管理功能。支持内容对象识别、版本控制、变更管理、变更审核和报告的功能元素和关联工作流。

  • Configuration management functions. The functional elements and associated workflow that support content object identification, version control, change management, change auditing, and reporting.

除了这些元素之外,管理子系统还实现管理功能,其中包含控制内容整体结构及其支持方式的元数据和规则。

In addition to these elements, the management subsystem implements an administration function that encompasses the metadata and rules that control the overall structure of the content and the manner in which it is supported.

发布子系统。内容必须从存储库中提取,转换为适合发布的形式并格式化,以便可以传输到客户端屏幕显示。发布子系统使用一系列模板来完成这些任务。每个模板都是一个使用三个不同组件之一构建出版物的函数 [Boi04]:

The Publishing Subsystem. Content must be extracted from the repository, converted to a form that is amenable to publication and formatted so that it can be transmitted to client-side screen displays. The publishing subsystem accomplishes these tasks using a series of templates. Each template is a function that builds a publication using one of three different components [Boi04]:

  • 静态元素。不需要进一步处理的文本、图形、媒体和脚本直接传输到客户端。

  • Static elements. Text, graphics, media, and scripts that require no further processing are transmitted directly to the client side.

  • 出版服务。对特定检索和格式化服务的函数调用,这些服务可个性化内容(使用预定义规则)、执行数据转换并构建适当的导航链接。

  • Publication services. Function calls to specific retrieval and formatting services that personalize content (using predefined rules), perform data conversion, and build appropriate navigation links.

  • 外部服务。访问外部企业信息基础设施,例如企业数据或“后台”应用程序。

  • External services. Access to external corporate information infrastructure such as enterprise data or “backroom” applications.

包含每个子系统的内容管理系统适用于主要的 Web 和移动项目。然而,与 CMS 相关的基本原理和功能适用于所有动态应用程序。

A content management system that encompasses each of these subsystems is applicable for major Web and mobile projects. However, the basic philosophy and functionality associated with a CMS are applicable to all dynamic applications.

22.6.4 版本控制

22.6.4 Version Control

随着应用程序和游戏通过一系列增量不断发展,可能会同时存在许多不同的版本。最终用户可以通过互联网获得一个版本(当前运行的应用程序);另一个版本(下一个应用程序增量)可能处于部署前测试的最后阶段;第三个版本正在开发中,代表了内容、界面美观和功能方面的重大更新。必须明确定义配置对象,以便每个配置对象都可以与适当的版本相关联。如果没有某种类型的控制,开发人员和内容创建者可能最终会覆盖彼此的更改。

As apps and games evolve through a series of increments, a number of different versions may exist at the same time. One version (the current operational app) is available via the Internet for end users; another version (the next app increment) may be in the final stages of testing prior to deployment; a third version is in development and represents a major update in content, interface aesthetics, and functionality. Configuration objects must be clearly defined so that each can be associated with the appropriate version. Without some type of control, developers and content creators may end up overwriting each other’s changes.

您很可能也经历过类似的情况。为了避免这种情况,需要版本控制过程。

It’s likely that you’ve experienced a similar situation. To avoid it, a version control process is required.

  1. 应建立应用程序或游戏项目的中央存储库。存储库将保存所有配置对象(内容、功能组件等)的当前版本。第458页

  2. A central repository for the app or game project should be established. The repository will hold current versions of all configuration objects (content, functional components, and others).Page 458

  3. 每个开发人员都会创建自己的工作文件夹。该文件夹包含在任何给定时间创建或更改的对象。

  4. Each developer creates his own working folder. The folder contains those objects that are being created or changed at any given time.

  5. 所有开发人员工作站上的时钟应该同步。这样做是为了避免当两个开发人员进行的更新时间非常接近时发生覆盖冲突。

  6. The clocks on all developer workstations should be synchronized. This is done to avoid overwriting conflicts when two developers make updates that are very close to one another in time.

  7. 随着新配置对象的开发或现有对象的更改,它们将被导入到中央存储库中。版本控制工具将管理每个开发人员工作文件夹中的所有签入和签出功能。当存储库发生更改时,该工具还应该向所有感兴趣的各方提供自动电子邮件更新。

  8. As new configuration objects are developed or existing objects are changed, they are imported into the central repository. The version control tool will manage all check-in and check-out functions from the working folders of each developer. The tool should also provide automatic e-mail updates to all interested parties when changes to the repository are made.

  9. 当对象从存储库导入或导出时,会自动生成带时间戳的日志消息。这为审计提供了有用的信息,并且可以成为有效报告方案的一部分。

  10. As objects are imported or exported from the repository, an automatic, time-stamped log message is made. This provides useful information for auditing and can become part of an effective reporting scheme.

版本控制工具维护应用程序的不同版本,并且可以根据需要恢复到旧版本。

The version control tool maintains different versions of the app and can revert to an older version if required.

22.6.5 审计和报告

22.6.5 Auditing and Reporting

为了敏捷性,在游戏或应用程序的开发过程中不再强调审计和报告功能。9然而,它们并没有被完全消除。签入或签出存储库的所有对象都记录在日志中,可以随时查看该日志。可以创建完整的日志报告,以便团队的所有成员都有指定时间段内更改的时间顺序。此外,每次将对象签入或签出存储库时,都会发送自动电子邮件通知(发送给感兴趣的开发人员和利益相关者)。

In the interest of agility, the auditing and reporting functions are deemphasized during the development of games or apps.9 However, they are not eliminated altogether. All objects that are checked into or out of the repository are recorded in a log that can be reviewed at any point in time. A complete log report can be created so that all members of the team have a chronology of changes over a defined period of time. In addition, an automated e-mail notification (addressed to those developers and stakeholders who have interest) can be sent every time an object is checked in or out of the repository.

22.7 总结

22.7 Summary

软件配置管理是贯穿整个软件流程的一项总括活动。SCM 识别、控制、审核和报告在软件开发期间以及将其发布给客户之后总是发生的修改。作为软件工程的一部分创建的所有工作产品都成为软件配置的一部分。配置的组织方式可以实现对变更的有序控制。

Software configuration management is an umbrella activity that is applied throughout the software process. SCM identifies, controls, audits, and reports modifications that invariably occur while software is being developed and after it has been released to a customer. All work products created as part of software engineering become part of a software configuration. The configuration is organized in a manner that enables orderly control of change.

软件配置由一组相互关联的对象(也称为软件配置项)组成,这些对象是由于某些软件工程活动而产生的。除了软件工程工作产品之外,用于创建软件的开发环境也可以置于配置控制之下。所有SCI都存储在一个存储库中,该存储库实现了一组机制和数据结构,以确保数据完整性,为其他软件工具提供集成支持,支持软件团队所有成员之间的信息共享,并实现支持版本和变更控制的功能。第 459 页

The software configuration is composed of a set of interrelated objects, also called software configuration items, that are produced as a result of some software engineering activity. In addition to software engineering work products, the development environment that is used to create software can also be placed under configuration control. All SCIs are stored within a repository that implements a set of mechanisms and data structures to ensure data integrity, provide integration support for other software tools, support information sharing among all members of the software team, and implement functions in support of version and change control.Page 459

一旦配置对象被开发和审查,它就成为基线。对基线对象的更改会导致创建该对象的新版本。可以通过检查所有配置对象的修订历史记录来跟踪程序的演变。版本控制是用于管理这些对象的使用的一组过程和工具。

Once a configuration object has been developed and reviewed, it becomes a baseline. Changes to a baselined object result in the creation of a new version of that object. The evolution of a program can be tracked by examining the revision history of all configuration objects. Version control is the set of procedures and tools for managing the use of these objects.

更改控制是一种程序活动,可确保对配置对象进行更改时的质量和一致性。变更控制流程从变更请求开始,导致做出或拒绝变更请求的决定,并以要变更的 SCI 的受控更新结束。

Change control is a procedural activity that ensures quality and consistency as changes are made to a configuration object. The change control process begins with a change request, leads to a decision to make or reject the request for change, and culminates with a controlled update of the SCI that is to be changed.

配置审核是一项 SQA 活动,有助于确保在进行更改时保持质量。状态报告向需要了解的人员提供有关每次更改的信息。

The configuration audit is an SQA activity that helps to ensure that quality is maintained as changes are made. Status reporting provides information about each change to those with a need to know.

应用程序或游戏的配置管理在大多数方面与传统软件的 SCM 相似。然而,每个核心 SCM 任务都应该精简,使其尽可能精简,并且必须实施内容管理的特殊规定。

Configuration management for apps or games is similar in most respects to SCM for conventional software. However, each of the core SCM tasks should be streamlined to make it as lean as possible, and special provisions for content management must be implemented.

问题与思考点

Problems and Points to Ponder

22.1。为什么系统工程第一定律是正确的?为变革的四个基本原因中的每一个提供具体示例。

22.1. Why is the first law of system engineering true? Provide specific examples for each of the four fundamental reasons for change.

22.2. 实施有效的SCM系统时存在哪四个要素?简要讨论每一项。

22.2. What are the four elements that exist when an effective SCM system is implemented? Discuss each briefly.

22.3。假设您是一个小项目的经理。您将为项目定义哪些基线?您将如何控制它们?

22.3. Assume that you’re the manager of a small project. What baselines would you define for the project, and how would you control them?

22.4。设计一个项目数据库(存储库)系统,使软件工程师能够存储、交叉引用、跟踪、更新、更改等所有重要的软件配置项。数据库如何处理同一程序的不同版本?源代码的处理方式是否与文档不同?如何防止两个开发人员同时对同一个 SCI 进行不同的更改?

22.4. Design a project database (repository) system that would enable a software engineer to store, cross-reference, trace, update, change, and so forth all important software configuration items. How would the database handle different versions of the same program? Would source code be handled differently than documentation? How will two developers be precluded from making different changes to the same SCI at the same time?

22.5。研究现有的 SCM 工具,并描述它如何实现对版本、变体和配置对象的总体控制。

22.5. Research an existing SCM tool, and describe how it implements control for versions, variants, and configuration objects in general.

22.6。研究现有的 SCM 工具,并描述它如何实现版本控制机制。或者,阅读两到三篇有关 SCM 的论文,并描述用于版本控制的不同数据结构和引用机制。

22.6. Research an existing SCM tool, and describe how it implements the mechanics of version control. Alternatively, read two or three papers on SCM and describe the different data structures and referencing mechanisms that are used for version control.

22.7。制定在配置审核期间使用的清单。

22.7. Develop a checklist for use during configuration audits.

22.8。SCM审核和技术审核有什么区别?他们的功能可以合并到一篇评论中吗?优缺点都有什么?

22.8. What is the difference between an SCM audit and a technical review? Can their function be folded into one review? What are the pros and cons?

22.9。简要描述传统软件的SCM与WebApps或MobileApps的SCM之间的差异。

22.9. Briefly describe the differences between SCM for conventional software and SCM for WebApps or MobileApps.

22.10。描述持续集成工具对敏捷软件开发人员的价值。

22.10. Describe the value of continuous integration tools to agile software developers.

1软件工程学院授予复制 Susan Dart [Dar01] 的“CM 系统功能谱”的特别许可,© 2001 卡内基梅隆大学。

1 Special permission to reproduce “Spectrum of Functionality in CM Systems” by Susan Dart [Dar01], © 2001 by Carnegie Mellon University is granted by the Software Engineering Institute.

2这些关系是在数据库中定义的。数据库(存储库)的结构将在第 22.2 节中进行更详细的讨论。

2 These relationships are defined within the database. The structure of the database (repository) is discussed in greater detail in Section 22.2.

3影响管理将在第 22.5.2 节中进一步讨论。

3 Impact management is discussed further in Section 22.5.2.

4还可以查询系统模型以评估一个组件的更改将如何影响其他组件。

4 It is also possible to query the system model to assess how a change in one component will impact other components.

5 Github (https://github.com/)、Perforce (https://www.perforce.com/) 和 Apache Subversion 也称为 SVN (http://subversion.apache.org/) 是流行的版本控制系统。

5 Github (https://github.com/), Perforce (https://www.perforce.com/), and Apache Subversion also known as SVN (http://subversion.apache.org/) are popular version control systems.

6 Puppet (https://puppet.com/)、Jenkins (https://jenkins.io/) 和 Hudson (http://hudson-ci.org/) 是 CI 工具的示例。Travis-CI (https://travis-ci.org/) 是一个 CI 工具,专为同步 Github 上的项目而设计。

6 Puppet (https://puppet.com/), Jenkins (https://jenkins.io/), and Hudson (http://hudson-ci.org/) are examples of CI tools. Travis-CI (https://travis-ci.org/) is a CI tool designed for sync projects residing on Github.

7也可以出于其他原因创建基线。例如,当创建“每日构建”时,给定时间签入的所有组件将成为第二天工作的基线。

7 A baseline can be created for other reasons as well. For example, when “daily builds” are created, all components checked in by a given time become the baseline for the next day’s work.

8有关 Web 工程方法的全面讨论,请参阅 [Pre08]。

8 See [Pre08] for a comprehensive discussion of Web engineering methods.

9这种情况正在开始改变。人们越来越重视 SCM 作为应用程序安全性的一个要素 [Fug14]。通过提供一种跟踪和报告对每个应用程序对象所做的每个更改的机制,更改管理工具可以针对恶意更改提供有价值的保护。

9 This is beginning to change. There is an increasing emphasis on SCM as one element of application security [Fug14]. By providing a mechanism for tracking and reporting every change made to every application object, a change management tool can provide valuable protection against malicious changes.

第460页

Page 460

章节

chapter

23软件指标和分析

23 Software Metrics and Analytics

任何工程过程的关键要素都是测量。测量可以应用于软件过程,目的是持续改进它。测量可用于整个软件项目,以协助估算、质量控制、生产力评估和项目控制。您可以使用度量来更好地了解您创建的模型的属性,并评估您构建的工程产品或系统的质量。

A key element of any engineering process is measurement. Measurement can be applied to the software process with the intent of improving it on a continuous basis. Measurement can be used throughout a software project to assist in estimation, quality control, productivity assessment, and project control. You can use measures to better understand the attributes of the models that you create and to assess the quality of the engineered products or systems that you build.

第461页软件工程师可以使用测量来帮助评估工作产品的质量,并在项目进行过程中协助制定战术决策。但与其他工程学科不同,软件工程并不以物理的基本定量定律为基础。电压、质量、速度或温度等直接测量在软件世界中并不常见。由于软件测量和指标通常是间接的,因此可以进行争论。

Page 461Measurement can be used by software engineers to help assess the quality of work products and to assist in tactical decision making as a project proceeds. But unlike other engineering disciplines, software engineering is not grounded in the basic quantitative laws of physics. Direct measures, such as voltage, mass, velocity, or temperature, are uncommon in the software world. Because software measures and metrics are often indirect, they are open to debate.

在软件流程和使用该流程进行的项目的背景下,软件团队主要关注生产力和质量指标——软件开发“输出”的衡量标准,作为所付出的努力和时间的函数,以及“适应度”的衡量标准用于使用”所生产的工作产品。出于规划和估计的目的,我们的兴趣是历史性的。过去项目的软件开发效率是多少?所生产的软件质量如何?如何将过去的生产力和质量数据推断到现在?它如何帮助我们更准确地计划和估算?

Within the context of the software process and the projects that are conducted using the process, a software team is concerned primarily with productivity and quality metrics—measures of software development “output” as a function of effort and time applied and measures of the “fitness for use” of the work products that are produced. For planning and estimating purposes, our interest is historical. What was software development productivity on past projects? What was the quality of the software that was produced? How can past productivity and quality data be extrapolated to the present? How can it help us plan and estimate more accurately?

测量是一种管理和技术工具。如果操作得当,它会给你带来洞察力。因此,它可以帮助项目经理和软件团队做出决策,从而实现项目的成功。

Measurement is a management and technical tool. If conducted properly, it provides you with insight. And as a result, it assists the project manager and the software team in making decisions that will lead to a successful project.

在本章中,我们提出了可用于评估产品设计质量的措施。我们还提出了可用于帮助管理软件项目的措施。这些措施为您提供软件流程(分析、设计、测试)有效性以及正在构建的软件整体质量的实时指示。

In this chapter, we present measures that can be used to assess the quality of the product as it is being engineered. We also present measures that can be used to help manage software projects. These measures provide you with a real-time indication of the effectiveness of your software processes (analysis, design, testing) and the overall quality of the software as it is being built.

23.1 软件测量

23.1 Software Measurement

数据科学1涉及测量、机器学习以及基于这些测量对未来事件的预测。测量将数字或符号分配给现实世界中实体的属性。为了实现这一点,需要一个包含一组一致规则的测量模型。尽管测量理论(例如,[Kyb84])及其在计算机软件中的应用(例如,[Zus97])超出了本书的范围,但建立一个基本框架和一组基本原理是值得的。指导软件开发指标的定义。

Data science1 is concerned with measurement, machine learning, and prediction of future events based on these measures. Measurement assigns numbers or symbols to attributes of entities in the real word. To accomplish this, a measurement model encompassing a consistent set of rules is required. Although the theory of measurement (e.g., [Kyb84]) and its application to computer software (e.g., [Zus97]) are topics that are beyond the scope of this book, it is worthwhile to establish a fundamental framework and a set of basic principles that guide the definition of metrics for software development.

23.1.1 措施、指标和指标

23.1.1 Measures, Metrics, and Indicators

尽管测量、度量度量这三个术语经常互换使用,但重要的是要注意它们之间的细微差别。当收集到单个数据点(例如,单个软件组件内发现的错误数量)时,就建立了衡量标准。测量是收集一个或多个数据点的结果(例如,调查许多组件审查和单元测试以收集每个数据点的错误数量的测量结果)。软件度量以某种方式将各个测量关联起来(例如,每次审查发现的错误平均数或每个单元测试发现的平均错误数)。第462页

Although the terms measure, measurement, and metrics are often used interchangeably, it is important to note the subtle differences between them. When a single data point has been collected (e.g., the number of errors uncovered within a single software component), a measure has been established. Measurement occurs as the result of the collection of one or more data points (e.g., a number of component reviews and unit tests are investigated to collect measures of the number of errors for each). A software metric relates the individual measures in some way (e.g., the average number of errors found per review or the average number of errors found per unit test).Page 462

软件工程师收集测量值并开发指标,以便获得指标。指标是一个度量或度量组合,可提供对软件流程、软件项目或产品本身的深入了解

A software engineer collects measures and develops metrics so that indicators will be obtained. An indicator is a metric or combination of metrics that provides insight into the software process, a software project, or the product itself.

23.1.2 有效软件度量的属性

23.1.2 Attributes of Effective Software Metrics

人们已经为计算机软件提出了数百种度量标准,但并非所有度量标准都能为软件工程师提供实际支持。有些需求测量过于复杂;另一些则非常深奥,以至于现实世界中的专业人士很少有希望理解它们,而另一些则违反了高质量软件的基本直观概念。经验表明,只有直观且易于计算的指标才会被使用。如果必须进行数十次“计数”,并且需要复杂的计算,则该指标不太可能被广泛采用。

Hundreds of metrics have been proposed for computer software, but not all provide practical support to the software engineer. Some demand measurement that is too complex; others are so esoteric that few real-world professionals have any hope of understanding them, and others violate the basic intuitive notions of what high-quality software really is. Experience indicates that a metric will be used only if it is intuitive and easy to compute. If dozens of “counts” have to be made, and complex computations are required, it is unlikely that the metric will be widely adopted.

Ejiogu [Eji91] 定义了一组应包含在有效软件度量中的属性。学习如何导出度量应该相对容易,并且其计算不应该需要过多的精力或时间。该度量应该满足工程师对所考虑的产品属性的直观概念(例如,测量模块内聚性的度量应该随着内聚水平的增加而增加值)。该指标应该始终产生明确的结果。度量的数学计算应该使用不会导致奇怪的单位组合的度量。例如,通过程序中的编程语言变量来增加项目团队的人员数量,会导致单元的可疑组合,这些单元在直观上没有说服力。指标应该基于需求模型、设计模型或程序本身的结构。它们不应该依赖于编程语言语法或语义的变幻莫测。最后,该指标应该为您提供可以带来更高质量的最终产品的信息。

Ejiogu [Eji91] defines a set of attributes that should be encompassed by effective software metrics. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time. The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration (e.g., a metric that measures module cohesion should increase in value as the level of cohesion increases). The metric should always yield results that are unambiguous. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of units. For example, multiplying people on the project teams by programming language variables in the program results in a suspicious mix of units that are not intuitively persuasive. Metrics should be based on the requirements model, the design model, or the structure of the program itself. They should not be dependent on the vagaries of programming language syntax or semantics. Finally, the metric should provide you with information that can lead to a higher-quality end product.

23.2 软件分析

23.2 Software Analytics

关于软件指标和软件分析之间的差异存在一些混淆。软件指标用于衡量产品或流程的质量或性能。关键绩效指标(KPI) 是用于跟踪绩效并在其值落在预定范围内时触发补救措施的指标。但您首先如何知道指标有意义呢?

There is some confusion about the differences between software metrics and software analytics. Software metrics are used to gauge the quality or performance of a product or process. Key performance indicators (KPIs) are metrics that are used to track performance and trigger remedial actions when their values fall in a predetermined range. But how do you know that metrics are meaningful in the first place?

软件分析是对软件工程数据或统计数据的系统计算分析,为经理和软件工程师提供有意义的见解,并使他们的团队能够做出更好的决策[Bus12]。这些见解为开发人员提供及时、可行的建议非常重要。例如,了解今天软件产品的缺陷数量并不重要,重要的是了解缺陷数量比上个月增加了 5%。分析可以帮助开发人员预测预期的缺陷数量、在哪里测试这些缺陷以及修复这些缺陷需要多长时间。这使得管理人员和开发人员可以创建增量计划,使用这些预测来确定预期的完成时间。需要使用能够处理大型动态工程指标和测量数据集的自动化工具 [Men13],以提供对大型项目和产品数据集的实时洞察。第463页

Software analytics is the systematic computational analysis of software engineering data or statistics to provide managers and software engineers with meaningful insights and empower their teams to make better decisions [Bus12]. It is important that the insights provide timely, actionable advice to developers. For example, knowing the number of defects in a software product today is not as important as knowing the number of defects is 5 percent higher than last month. Analytics can help developers predict the number of defects to expect, where to test for them, and how much time it will take to fix them. This allows managers and developers to create incremental schedules that use these predictions to determine expected completion times. The use of automated tools capable of processing large, dynamic data sets of engineering metrics and measures [Men13] is required to provide real-time insight into large project and product data sets.Page 463

Buse 和 Zimmermann [Bus12] 建议分析可以帮助开发人员做出以下方面的决策:

Buse and Zimmermann [Bus12] suggest that analytics can help developers make decisions regarding:

  • 有针对性的测试。帮助集中回归测试和集成测试资源

  • Targeted testing. To help focus regression testing and integration testing resources

  • 有针对性的重构。帮助做出如何避免巨额技术债务成本的战略决策

  • Targeted refactoring. To help make strategic decisions on how to avoid large technical debt costs

  • 发布策划。帮助确保考虑到市场需求以及软件产品的技术特性

  • Release planning. To help ensure that market needs as well as technical features in software product are taken into account

  • 了解客户。帮助开发人员在产品工程期间获得有关客户在现场使用产品的可操作信息

  • Understanding customers. To help developers get actionable information on product use by customers in the field during product engineering

  • 判断稳定性。帮助管理人员和开发人员监控不断发展的原型的状态并预测未来的维护需求

  • Judging stability. To help managers and developers monitor the state of the evolving prototype and anticipate future maintenance needs

  • 针对性检查。帮助团队确定单独检查活动的价值、频率和范围

  • Targeting inspection. To help teams determine the value of individual inspection activities, their frequency, and their scope

进行软件分析工作所需的统计技术(数据挖掘、机器学习、统计建模)超出了本书的范围。附录 2简要讨论了其中一些技术。我们将在本章的其余部分重点讨论软件指标的使用。

The statistical techniques (data mining, machine learning, statistical modeling) required to do software analytic work is beyond the scope of this book. Some of these techniques are discussed briefly in Appendix 2. We will focus on the use of software metrics in the remainder of this chapter.

23.3 产品指标

23.3 Product Metrics

在过去的四十年中,许多研究人员试图开发一个单一的度量标准来提供软件复杂性的综合度量。芬顿 [Fen94] 将这项研究描述为寻找“不可能的圣杯”。尽管已经提出了数十种复杂性度量方法[Zus90],但每种方法对于复杂性是什么以及系统的哪些属性导致复杂性的看法都有些不同。通过类比,考虑一个评估有吸引力的汽车的指标。一些观察家可能会强调车身设计;但有些人可能会强调车身设计。其他人可能会考虑机械特性;还有一些人可能会宣传成本、性能、替代燃料的使用,或者汽车报废时的回收能力。由于这些特征中的任何一个都可能与其他特征不一致,因此很难得出“吸引力”的单一值。计算机软件也会出现同样的问题。

Over the past four decades, many researchers have attempted to develop a single metric that provides a comprehensive measure of software complexity. Fenton [Fen94] characterizes this research as a search for “the impossible holy grail.” Although dozens of complexity measures have been proposed [Zus90], each takes a somewhat different view of what complexity is and what attributes of a system lead to complexity. By analogy, consider a metric for evaluating an attractive car. Some observers might emphasize body design; others might consider mechanical characteristics; still others might tout cost, or performance, or the use of alternative fuels, or the ability to recycle when the car is junked. Because any one of these characteristics may be at odds with others, it is difficult to derive a single value for “attractiveness.” The same problem occurs with computer software.

然而,需要测量和控制软件复杂性。如果很难得出这个质量度量的单一值,那么应该可以开发不同内部程序属性的度量(例如,有效的模块化、功能独立性和第 9 章中讨论的其他属性。这些度量以及从中得出的度量可以用作需求和设计模型质量的独立指标。但这里又出现了问题。芬顿 [Fen94] 指出了这一点,他指出:“试图找到表征如此多不同属性的措施的危险在于,这些措施不可避免地必须满足相互冲突的目标。这与表征测量理论背道而驰。” 尽管芬顿的说法是正确的,但许多人认为,在软件过程的早期阶段进行的产品测量为软件工程师提供了一致且客观的质量评估机制。2第464页

Yet there is a need to measure and control software complexity. And if a single value of this quality metric is difficult to derive, it should be possible to develop measures of different internal program attributes (e.g., effective modularity, functional independence, and other attributes discussed in Chapter 9). These measures and the metrics derived from them can be used as independent indicators of the quality of requirements and design models. But here again, problems arise. Fenton [Fen94] notes this when he states: “The danger of attempting to find measures which characterize so many different attributes is that inevitably the measures have to satisfy conflicting aims. This is counter to the representational theory of measurement.” Although Fenton’s statement is correct, many people argue that product measurement conducted during the early stages of the software process provides software engineers with a consistent and objective mechanism for assessing quality.2Page 464

23.3.1 需求模型的度量

23.3.1 Metrics for the Requirements Model

软件工程中的技术工作从需求模型的创建开始。正是在这个阶段,提出了需求并建立了设计基础。因此,需要能够深入了解分析模型质量的产品指标。

Technical work in software engineering begins with the creation of the requirements model. It is at this stage that requirements are derived and a foundation for design is established. Therefore, product metrics that provide insight into the quality of the analysis model are desirable.

尽管文献中出现的分析和规范指标相对较少,但可以调整经常用于项目估计(第 25.6 节)的指标(例如,用例点或功能点)并将其应用于上下文。这些估计指标检查需求模型,旨在预测最终系统的“规模”。大小有时(但不总是)是设计复杂性的指标,并且几乎总是增加编码、集成和测试工作量的指标。通过测量需求模型的特征,可以定量地了解其特殊性和完整性。第465页

Although relatively few analysis and specification metrics have appeared in the literature, it is possible to adapt metrics (e.g., use case points or function points) that are often used for project estimation (Section 25.6) and apply them in this context. These estimation metrics examine the requirements model with the intent of predicting the “size” of the resultant system. Size is sometimes (but not always) an indicator of design complexity and is almost always an indicator of increased coding, integration, and testing effort. By measuring characteristics of the requirements model, it is possible to gain quantitative insight into its specificity and completeness.Page 465

常规软件。Davis 和他的同事 [Dav93] 提出了一系列可用于评估需求模型和相应需求规范质量的特征:特异性(缺乏歧义)、完整性、正确性、可理解性、可验证性、内部和外部一致性、可实现性、简洁性、可追溯性、可修改性、精确性可重用性。此外,作者指出,高质量的规范是通过电子方式存储的;可执行或至少可解释;按相对重要性注释;稳定、版本化、有组织、交叉引用,并以正确的详细程度指定。

Conventional Software. Davis and his colleagues [Dav93] propose a list of characteristics that can be used to assess the quality of the requirements model and the corresponding requirements specification: specificity (lack of ambiguity), completeness, correctness, understandability, verifiability, internal and external consistency, achievability, concision, traceability, modifiability, precision, and reusability. In addition, the authors note that high-quality specifications are electronically stored; executable or at least interpretable; annotated by relative importance; and stable, versioned, organized, cross-referenced, and specified at the right level of detail.

尽管许多这些特征本质上看起来是定性的,但每个特征都可以使用一个或多个指标来表示 [Dav93]。例如,我们假设规范中有n r 个需求,这样

Although many of these characteristics appear to be qualitative in nature, each can be represented using one or more metrics [Dav93]. For example, we assume that there are nr requirements in a specification, such that

n r = n f + n nf

nr = nf + nnf

其中n f是功能需求的数量,n nf是非功能(例如性能)需求的数量。

where nf is the number of functional requirements and nnf is the number of nonfunctional (e.g., performance) requirements.

为了确定要求的特异性(不存在歧义),Davis 及其同事提出了一个基于审阅者对每个要求的解释的一致性的衡量标准:

To determine the specificity (lack of ambiguity) of requirements, Davis and colleagues suggest a metric that is based on the consistency of the reviewers’ interpretation of each requirement:

其中n ui是所有审阅者具有相同解释的要求数量。Q的值越接近1,规范的模糊性越低。其他特征以类似的方式计算。

where nui is the number of requirements for which all reviewers had identical interpretations. The closer the value of Q to 1, the lower is the ambiguity of the specification. Other characteristics are computed in a similar manner.

移动软件。所有移动项目的目标都是向最终用户提供内容和功能的组合。用于传统软件工程项目的措施和指标很难直接转化为移动应用程序。然而,可以开发在需求收集活动期间确定的衡量标准,这些衡量标准可以作为创建移动应用程序指标的基础。可以采取的措施如下:

Mobile Software. The objective of all mobile projects is to deliver a combination of content and functionality to the end user. Measures and metrics used for traditional software engineering projects are difficult to translate directly to MobileApps. Yet, it is possible to develop measures that can be determined during the requirements gathering activities that can serve as the basis for creating MobileApp metrics. Among the measures that can be collected are the following:

  • 静态屏幕显示的数量。这些页面的相对复杂性较低,并且通常比动态页面需要更少的精力来构建。该度量可以指示应用程序的总体大小以及开发它所需的工作量。

  • Number of static screen displays. These pages represent low relative complexity and generally require less effort to construct than dynamic pages. This measure provides an indication of the overall size of the application and the effort required to develop it.

  • 动态屏幕显示的数量。这些页面相对复杂性更高,并且比静态页面需要更多的精力来构建。该度量可以指示应用程序的总体大小以及开发它所需的工作量。第466页

  • Number of dynamic screen displays. These pages represent higher relative complexity and require more effort to construct than static pages. This measure provides an indication of the overall size of the application and the effort required to develop it.Page 466

  • 持久数据对象的数量。随着持久数据对象(例如数据库或数据文件)数量的增加,移动应用程序的复杂性也会增加,并且实现它的工作量也会成比例地增加。

  • Number of persistent data objects. As the number of persistent data objects (e.g., a database or data file) grows, the complexity of the MobileApp also grows and the effort to implement it increases proportionally.

  • 连接的外部系统数量。随着接口需求的增长,系统复杂性和开发工作量也随之增加。

  • Number of external systems interfaced. As the requirement for interfacing grows, system complexity and development effort also increase.

  • 静态内容对象的数量。这些对象的相对复杂性较低,并且通常比动态页面需要更少的工作来构建。

  • Number of static content objects. These objects represent low relative complexity and generally require less effort to construct than dynamic pages.

  • 动态内容对象的数量。这些对象表示较高的相对复杂性,并且比静态页面需要更多的精力来构建。

  • Number of dynamic content objects. These objects represent higher relative complexity and require more effort to construct than static pages.

  • 可执行函数的数量。随着可执行功能(例如,脚本或小程序)数量的增加,建模和构建工作量也会增加。

  • Number of executable functions. As the number of executable functions (e.g., a script or applet) increases, modeling and construction effort also increase.

例如,通过这些度量,您可以定义一个指标来反映移动应用程序所需的最终用户定制程度,并将其与项目上花费的精力和/或在进行审查和测试时发现的错误相关联。为了实现这一点,您定义

For example with these measures, you can define a metric that reflects the degree of end-user customization that is required for the MobileApp and correlate it to the effort expended on the project and/or the errors uncovered as reviews and testing are conducted. To accomplish this, you define

N sp = 静态屏幕显示数量

Nsp = number of static screen displays

N dp = 动态屏幕显示数量

Ndp = number of dynamic screen displays

然后,

Then,

C的值范围从0到1。随着C变大,应用程序定制的水平成为一个重要的技术问题。

The value of C ranges from 0 to 1. As C grows larger, the level of app customization becomes a significant technical issue.

可以计算类似的度量并将其与项目度量相关联,例如花费的精力、发现的错误和缺陷以及生成的模型或文档页面。如果这些指标的值与项目度量一起存储在数据库中(在完成多个项目之后),则应用程序需求度量和项目度量之间的关系将提供可以帮助完成项目评估任务的指标。

Similar metrics can be computed and correlated with project measures such as effort expended, errors and defects uncovered, and models or documentation pages produced. If the values of these metrics are stored in a database with project measures (after a number of projects have been completed), the relationships between the app requirement measures and project measures will provide indicators that can aid in project assessment tasks.

23.3.2 传统软件的设计指标

23.3.2 Design Metrics for Conventional Software

如果不定义设计措施、确定设计质量各个方面的指标,并用它们作为指导设计方式的指标,就无法想象一架新飞机、一种新计算机芯片或一座新办公楼的设计。设计不断发展。然而,复杂的基于软件的系统的设计通常几乎不需要任何测量。具有讽刺意味的是,软件的设计指标是可用的,但绝大多数软件工程师仍然不知道它们的存在。

It is inconceivable that the design of a new aircraft, a new computer chip, or a new office building would be conducted without defining design measures, determining metrics for various aspects of design quality, and using them as indicators to guide the manner in which the design evolves. And yet, the design of complex software-based systems often proceeds with virtually no measurement. The irony of this is that design metrics for software are available, but the vast majority of software engineers continue to be unaware of their existence.

架构设计指标侧重于程序架构的特征(第10章),重点是架构结构以及架构内模块或组件的有效性。这些指标是“黑匣子”,因为它们不需要了解特定软件组件的内部工作原理。指标可以深入了解与架构设计相关的结构数据和系统复杂性。第467页

Architectural design metrics focus on characteristics of the program architecture (Chapter 10) with an emphasis on the architectural structure and the effectiveness of modules or components within the architecture. These metrics are “black box” in the sense that they do not require any knowledge of the inner workings of a particular software component. Metrics can provide insight into structural data and system complexity associated with architectural design.Page 467

Card and Glass [Car90] 定义了三种软件设计复杂性度量:结构复杂性、数据复杂性和系统复杂性。

Card and Glass [Car90] define three software design complexity measures: structural complexity, data complexity, and system complexity.

对于分层架构(例如,调用和返回架构),模块i的结构复杂度按以下方式定义:

For hierarchical architectures (e.g., call-and-return architectures), structural complexity of a module i is defined in the following manner:

其中f out ( i ) 是模块i的扇出3

where fout(i) is the fan-out3 of module i.

数据复杂性指示了模块i的内部接口的复杂性,定义为

Data complexity provides an indication of the complexity in the internal interface for a module i and is defined as

其中v ( i ) 是传入和传出模块i的输入和输出变量的数量。

where v(i) is the number of input and output variables that are passed to and from module i.

最后,系统复杂度定义为结构复杂度和数据复杂度之和,指定为

Finally, system complexity is defined as the sum of structural and data complexity, specified as

C ( i )= S ( i )+ D ( i )

C(i) = S(i) + D(i)

随着这些复杂性值中每一个的增加,系统的整体架构复杂性也会增加。这导致集成和测试工作量也更有可能增加。

As each of these complexity values increases, the overall architectural complexity of the system also increases. This leads to a greater likelihood that integration and testing effort will also increase.

Fenton [Fen91]提出了许多简单的形态(即形状)度量,使不同的程序架构能够使用一组简单的维度进行比较。参考图23.1中的调用和返回架构,可以定义以下指标:

Fenton [Fen91] suggests a number of simple morphology (i.e., shape) metrics that enable different program architectures to be compared using a set of straightforward dimensions. Referring to the call-and-return architecture in Figure 23.1, the following metrics can be defined:

图23.1形态学 指标

Figure 23.1 Morphology metrics

大小 = n + a

Size = n + a

其中n是节点数,a是弧数。对于图23.1所示的架构,

where n is the number of nodes and a is the number of arcs. For the architecture shown in Figure 23.1,

尺寸 = 17 + 18 = 35

Size = 17 + 18 = 35

深度 = 从根(顶部)节点到叶节点的最长路径。对于图 23.1 所示的架构,深度 = 4。

Depth = longest path from the root (top) node to a leaf node. For the architecture shown in Figure 23.1, depth = 4.

宽度 = 架构中任意一层的最大节点数。对于图 23.1 所示的架构,宽度 = 6。

Width = maximum number of nodes at any one level of the architecture. For the architecture shown in Figure 23.1, width = 6.

弧与节点的比率,r = a/n,测量架构的连接密度,并且可以提供架构耦合的简单指示。对于图 23.1 所示的架构,r = 18/17 = 1.06。

The arc-to-node ratio, r = a/n, measures the connectivity density of the architecture and may provide a simple indication of the coupling of the architecture. For the architecture shown in Figure 23.1, r = 18/17 = 1.06.

美国空军系统司令部 [USA87] 开发了许多基于计算机程序的可测量设计特征的软件质量指标。使用与 IEEE 标准中提出的概念类似的概念。982.1-2005 [IEE05],空军使用从数据和架构设计中获得的信息来得出范围从 0 到 1 的设计结构质量指数(DSQI)(详细信息请参阅:[USA87] 和 [Cha89])。第468页

The U.S. Air Force Systems Command [USA87] has developed a number of software quality indicators that are based on measurable design characteristics of a computer program. Using concepts similar to those proposed in IEEE Std. 982.1-2005 [IEE05], the Air Force uses information obtained from data and architectural design to derive a design structure quality index (DSQI) that ranges from 0 to 1 (see: [USA87] and [Cha89] for details).Page 468

23.3.3 面向对象软件的设计指标

23.3.3 Design Metrics for Object-Oriented Software

面向对象的设计有很多是主观的——经验丰富的设计师“知道”如何描述 OO 系统的特征,以便有效地实现客户的需求。但是,随着 OO 设计模型规模和复杂性的增长,对设计特征的更客观的看法可以使经验丰富的设计师(获得额外的洞察力)和新手(获得本来无法获得的质量指示)受益。 )。

There is much about object-oriented design that is subjective—an experienced designer “knows” how to characterize an OO system so that it will effectively implement customer requirements. But, as an OO design model grows in size and complexity, a more objective view of the characteristics of the design can benefit both the experienced designer (who gains additional insight) and the novice (who obtains an indication of quality that would otherwise be unavailable).

在对 OO 系统的软件度量的详细处理中,Whitmire [Whi97] 描述了 OO 设计的九个不同且可测量的特征。大小是通过对 OO 实体(例如类或操作)进行静态计数以及继承树的深度来定义的。复杂性是通过检查 OO 设计的类如何相互关联而根据结构特征来定义的。耦合度是通过计算 OO 设计元素之间的物理连接来衡量的(例如,类之间的协作数量或对象之间传递的消息数量)。充分性是“抽象[类]拥有其所需特征的程度。。”。[Wh97]。完整性决定了一个类是否提供了完全反映问题域需求的属性集。凝聚力是通过检查所有操作是否协同工作以实现单一的、明确定义的目的来确定的。原始性是指操作的原子性程度,即该操作不能由类中包含的一系列其他操作构成。相似性决定了两个或多个类在结构、功能、行为或目的方面的相似程度。波动性衡量发生变化的可能性。第469页

In a detailed treatment of software metrics for OO systems, Whitmire [Whi97] describes nine distinct and measurable characteristics of an OO design. Size is defined by taking a static count of OO entities such as classes or operations, coupled with the depth of an inheritance tree. Complexity is defined in terms of structural characteristics by examining how classes of an OO design are interrelated to one another. Coupling is measured by counting physical connections between elements of the OO design (e.g., the number of collaborations between classes or the number of messages passed between objects). Sufficiency is “the degree to which an abstraction [class] possesses the features required of it . . .” [Whi97]. Completeness determines whether a class delivers the set of properties that fully reflect the needs of the problem domain. Cohesion is determined be examining whether all operations work together to achieve a single, well-defined purpose. Primitiveness is the degree to which an operation is atomic—that is, the operation cannot be constructed out of a sequence of other operations contained within a class. Similarity determines the degree to which two or more classes are similar in terms of their structure, function, behavior, or purpose. Volatility measures the likelihood that a change will occur.Page 469

实际上,面向对象系统的产品度量不仅可以应用于设计模型,还可以应用于需求模型。在本节的其余部分中,我们将讨论提供 OO 类级别和操作级别的质量指示的度量标准。此外,还探讨了适用于项目管理和测试的指标。

In reality, product metrics for OO systems can be applied not only to the design model, but also to the requirements model. In the remainder of this section, we discuss metrics that provide an indication of quality at the OO class level and the operation level. In addition, metrics applicable for project management and testing are also explored.

Chidamber 和 Kemerer (CK) 提出了引用最广泛的 OO 软件度量集之一 [Chi94]。4通常被称为CK 度量套件,作者为 OO 系统提出了六种基于类的设计度量。5

Chidamber and Kemerer (CK) have proposed one of the most widely referenced sets of OO software metrics [Chi94].4 Often referred to as the CK metrics suite, the authors have proposed six class-based design metrics for OO systems.5

每类加权方法 (WMC)。假设有n 个复杂度为c 1 , c 2 , ...的方法。。。、cn是为C类定义的。选择的特定复杂度度量(例如,圈复杂度)应该被归一化,以便方法的标称复杂度取值1.0。

Weighted Methods per Class (WMC). Assume that n methods of complexity c1, c2, . . . , cn are defined for a class C. The specific complexity metric that is chosen (e.g., cyclomatic complexity) should be normalized so that nominal complexity for a method takes on a value of 1.0.

WMC = Σ c i

WMC = Σci

对于i = 1 到n。方法的数量及其复杂性是实现和测试类所需工作量的合理指标。另外,方法数量越多,继承树就越复杂(所有子类都继承父类的方法)。最后,随着给定类的方法数量的增加,它可能变得越来越特定于应用程序,从而限制了潜在的重用。出于所有这些原因,WMC 应保持在合理的较低水平。

for i = 1 to n. The number of methods and their complexity are reasonable indicators of the amount of effort required to implement and test a class. In addition, the larger the number of methods, the more complex is the inheritance tree (all subclasses inherit the methods of their parents). Finally, as the number of methods grows for a given class, it is likely to become more and more application specific, thereby limiting potential reuse. For all of these reasons, WMC should be kept as low as is reasonable.

继承树的深度 (DIT)。该度量是“从节点到树根的最大长度”[Chi94]。参考图23.2,所示类层次结构的DIT 值为4。随着DIT 的增长,较低级别的类很可能会继承许多方法。当尝试预测类的行为时,这会导致潜在的困难。深的类层次结构(DIT 很大)也会导致更大的设计复杂性。从积极的一面来看,大的 DIT 值意味着可以重用许多方法。

Depth of the Inheritance Tree (DIT). This metric is “the maximum length from the node to the root of the tree” [Chi94]. Referring to Figure 23.2, the value of DIT for the class hierarchy shown is 4. As DIT grows, it is likely that lower-level classes will inherit many methods. This leads to potential difficulties when attempting to predict the behavior of a class. A deep class hierarchy (DIT is large) also leads to greater design complexity. On the positive side, large DIT values imply that many methods may be reused.

儿童数量 (NOC)。在类层次结构中直接从属于某个类的子类称为其子类。参考图 23.2,类C 2有三个子类——子类C 21C 22C 23。随着子级数量的增加,重用也会增加,而且随着 NOC 的增加,如果某些子级不是父类的适当成员,则父类所表示的抽象可能会被稀释。随着 NOC 的增加,测试量(在其操作环境中锻炼每个孩子所需的)也会增加。

Number of Children (NOC). The subclasses that are immediately subordinate to a class in the class hierarchy are termed its children. Referring to Figure 23.2, class C2 has three children—subclasses C21, C22, and C23. As the number of children grows, reuse increases, but also, as NOC increases, the abstraction represented by the parent class can be diluted if some of the children are not appropriate members of the parent class. As NOC increases, the amount of testing (required to exercise each child in its operational context) will also increase.

对象类之间的耦合 (CBO)。CRC 模型(第 8 章)可用于确定 CBO 的值。本质上,CBO 是其 CRC 索引卡上列出的一个类别的协作数量。6随着 CBO 的增加,第 470 页类的可重用性将会降低。CBO 的高值也会使修改以及修改后进行的测试变得复杂。一般来说,每个类别的 CBO 值应保持在合理的最低水平。这与减少传统软件耦合的一般准则是一致的。

Coupling Between Object Classes (CBO). The CRC model (Chapter 8) may be used to determine the value for CBO. In essence, CBO is the number of collaborations listed for a class on its CRC index card.6 As CBO increases, it is likely that the Page 470reusability of a class will decrease. High values of CBO also complicate modifications and the testing that ensues when modifications are made. In general, the CBO values for each class should be kept as low as is reasonable. This is consistent with the general guideline to reduce coupling in conventional software.

对类的响应 (RFC)。类的响应集是“可以响应该类的对象接收到的消息而执行的一组方法”[Chi94]。RFC 是响应集中方法的数量。随着 RFC 的增加,测试所需的工作量也会增加,因为测试序列(第 20 章)会增加。由此可见,随着 RFC 的增加,类的整体设计复杂性也会增加。

Response for a Class (RFC). The response set of a class is “a set of methods that can potentially be executed in response to a message received by an object of that class” [Chi94]. RFC is the number of methods in the response set. As RFC increases, the effort required for testing also increases because the test sequence (Chapter 20) grows. It also follows that, as RFC increases, the overall design complexity of the class increases.

方法缺乏内聚性 (LCOM)。C中的每个方法都访问一个或多个属性(也称为实例变量)。LCOM 是访问一个或多个相同属性的方法的数量。7如果没有方法访问相同的属性,则 LCOM = 0。为了说明 LCOM ≠ 0 的情况,请考虑一个具有六个方法的类。其中四种方法具有一个或多个共同属性(即,它们访问共同属性)。因此,LCOM = 4。如果 LCOM 为高,则方法可以通过属性相互耦合。这增加了类设计的复杂性。尽管在某些情况下,LCOM 的高值是合理的,但希望保持高内聚性,即保持 LCOM 低。8第471页

Lack of Cohesion in Methods (LCOM). Each method within a class C accesses one or more attributes (also called instance variables). LCOM is the number of methods that access one or more of the same attributes.7 If no methods access the same attributes, then LCOM = 0. To illustrate the case where LCOM ≠ 0, consider a class with six methods. Four of the methods have one or more attributes in common (i.e., they access common attributes). Therefore, LCOM = 4. If LCOM is high, methods may be coupled to one another via attributes. This increases the complexity of the class design. Although there are cases in which a high value for LCOM is justifiable, it is desirable to keep cohesion high, that is, keep LCOM low.8Page 471

23.3.4 用户界面设计指标

23.3.4 User Interface Design Metrics

尽管有大量关于人机界面设计的文献(第 12 章),但有关可深入了解界面质量和可用性的指标的信息相对较少。尽管 UI 指标在某些情况下可能有用,但最终的仲裁者应该是基于 GUI 原型的用户输入。Nielsen 和 Levy [Nie94] 报告称,“如果一个人仅根据用户的意见在界面[设计]之间进行选择,那么成功的机会相当大。用户的平均任务表现和他们对 GUI 的主观满意度高度相关。”

Although there is significant literature on the design of human-computer interfaces (Chapter 12), relatively little information has been published on metrics that would provide insight into the quality and usability of the interface. Although UI metrics may be useful in some cases, the final arbiter should be user input based on GUI prototypes. Nielsen and Levy [Nie94] report that “one has a reasonably large chance of success if one chooses between interface [designs] based solely on users’ opinions. Users’ average task performance and their subjective satisfaction with a GUI are highly correlated.”

在接下来的段落中,我们提供了可能适用于网站、基于浏览器的应用程序和移动应用程序的具有代表性的设计指标样本。其中许多指标适用于所有用户界面。然而,值得注意的是,其中许多指标尚未经过验证,应谨慎使用。第472页

In the paragraphs that follow, we present a representative sampling of design metrics that may have application for websites, browser-based applications, and mobile applications. Many of these metrics are applicable to all user interfaces. It is important to note, however, that many of these metrics have not as yet been validated and should be used judiciously.Page 472

接口指标。对于WebApps,可以考虑以下接口措施:

Interface Metrics. For WebApps, the following interface measures can be considered:

美学(平面设计)指标。从本质上讲,美学设计依赖于定性判断,通常不适合测量和度量。然而,Ivory 和她的同事 [Ivo01] 提出了一组可能有助于评估美学设计影响的措施:

Aesthetic (Graphic Design) Metrics. By its nature, aesthetic design relies on qualitative judgment and is not generally amenable to measurement and metrics. However, Ivory and her colleagues [Ivo01] propose a set of measures that may be useful in assessing the impact of aesthetic design:

第473页

Page 473

内容指标。此类别中的指标侧重于内容复杂性和组织到页面中的内容对象集群[Men01]。

Content Metrics. Metrics in this category focus on content complexity and on clusters of content objects that are organized into pages [Men01].

导航指标。此类别中的指标解决了导航流的复杂性[Men01]。一般来说,它们仅适用于静态 Web 应用程序,不包括动态生成的链接和页面。

Navigation Metrics. Metrics in this category address the complexity of the navigational flow [Men01]. In general, they are applicable only for static Web applications, which don’t include dynamically generated links and pages.

使用建议的度量子集,可能会得出经验关系,使 WebApp 开发团队能够评估技术质量并根据预计的复杂性估计来预测工作量。该领域仍有待完成进一步的工作。

Using a subset of the metrics suggested, it may be possible to derive empirical relations that allow a WebApp development team to assess technical quality and predict effort based on projected estimates of complexity. Further work remains to be accomplished in this area.

23.3.5 源代码的指标

23.3.5 Metrics for Source Code

霍尔斯特德的“软件科学”理论[Hal77]提出了计算机软件的第一个分析“定律”。10 Halstead 为计算机软件的开发分配了定量法则,使用了一组原始度量,这些度量可以在设计完成后生成或估计代码后导出。措施是:

Halstead’s theory of “software science” [Hal77] proposed the first analytical “laws” for computer software.10 Halstead assigned quantitative laws to the development of computer software, using a set of primitive measures that may be derived after code is generated or estimated once design is complete. The measures are:

n 1 = 程序中出现的不同运算符的数量

n1 = number of distinct operators that appear in a program

n 2 = 程序中出现的不同操作数的数量

n2 = number of distinct operands that appear in a program

N 1 = 运算符出现的总数

N1 = total number of operator occurrences

N 2 = 操作数出现的总数

N2 = total number of operand occurrences

第474页Halstead 使用这些原始度量来开发整体程序长度、算法的潜在最小体积、实际体积(指定程序所需的位数)、程序级别(软件复杂性的度量)、语言级别(给定语言的常数),以及其他特征,例如开发工作、开发时间,甚至软件中预计的故障数量。

Page 474Halstead uses these primitive measures to develop expressions for the overall program length, potential minimum volume for an algorithm, the actual volume (number of bits required to specify a program), the program level (a measure of software complexity), the language level (a constant for a given language), and other features such as development effort, development time, and even the projected number of faults in the software.

Halstead 表明长度N可以估计为

Halstead shows that length N can be estimated as

N = n 1 log 2 n 1 + n 2 log 2 n 2

N = n1 log2 n1 + n2 log2 n2

节目量可以定义为

and program volume may be defined as

V = N log 2 ( n 1 + n 2 )

V = N log2 (n1 + n2)

应该注意的是,V将随编程语言的不同而变化,并且表示指定程序所需的信息量(以位为单位)。

It should be noted that V will vary with programming language and represents the volume of information (in bits) required to specify a program.

理论上,特定算法必须存在最小体积。Halstead 将体积比L定义为程序的最紧凑形式的体积与实际程序的体积的比率。实际上,L必须始终小于 1。就原始度量而言,体积比可表示为

Theoretically, a minimum volume must exist for a particular algorithm. Halstead defines a volume ratio L as the ratio of volume of the most compact form of a program to the volume of the actual program. In actuality, L must always be less than 1. In terms of primitive measures, the volume ratio may be expressed as

Halstead 的工作可以通过实验验证,并且已经进行了大量研究来调查软件科学。对这项工作的讨论超出了本书的范围。有关更多信息,请参阅 [Zus90]、[Fen91] 和 [Zus97]。

Halstead’s work is amenable to experimental verification, and a large body of research has been conducted to investigate software science. A discussion of this work is beyond the scope of this book. For further information, see [Zus90], [Fen91], and [Zus97].

23.4 测试指标

23.4 Metrics for Testing

测试指标分为两大类:(1) 尝试预测不同测试级别所需测试的可能数量的指标,以及 (2) 侧重于给定组件的测试覆盖率的指标。为测试提出的大多数指标都侧重于测试过程,而不是测试本身的技术特征。一般来说,测试人员必须依靠分析、设计和代码度量来指导他们设计和执行测试用例。

Testing metrics fall into two broad categories: (1) metrics that attempt to predict the likely number of tests required at various testing levels, and (2) metrics that focus on test coverage for a given component. The majority of metrics proposed for testing focus on the process of testing, not the technical characteristics of the tests themselves. In general, testers must rely on analysis, design, and code metrics to guide them in the design and execution of test cases.

架构设计指标提供了与集成测试相关的难易程度以及对专门测试软件(例如存根和驱动程序)的需求的信息。圈复杂度(组件级设计指标)是基本路径测试的核心,这是第 19 章中介绍的一种测试用例设计方法。此外,圈复杂度可用于将模块作为广泛单元测试的候选目标。具有高圈复杂度的模块比圈复杂度较低的模块更容易出错。因此,在将此类模块集成到系统中之前,您应该付出高于平均水平的努力来发现这些模块中的错误。

Architectural design metrics provide information on the ease or difficulty associated with integration testing and the need for specialized testing software (e.g., stubs and drivers). Cyclomatic complexity (a component-level design metric) lies at the core of basis path testing, a test-case design method presented in Chapter 19. In addition, cyclomatic complexity can be used to target modules as candidates for extensive unit testing. Modules with high cyclomatic complexity are more likely to be error prone than modules whose cyclomatic complexity is lower. For this reason, you should expend above-average effort to uncover errors in such modules before they are integrated in a system.

测试工作量可以使用 Halstead 测量得出的指标来估计(第 23.3.5 节)。使用程序量V和程序级别PL的定义 Halstead 努力e可以计算为

Testing effort can be estimated using metrics derived from Halstead measures (Section 23.3.5). Using the definitions for program volume V and program level PL, Halstead effort e can be computed as

第 475 页分配给模块k 的总体测试工作的百分比可以使用以下关系来估计:

Page 475The percentage of overall testing effort to be allocated to a module k can be estimated using the following relationship:

其中e ( k ) 是针对模块k计算的,分母中的总和是系统所有模块的 Halstead 努力的总和。

where e(k) is computed for module k and the summation in the denominator is the sum of Halstead effort across all modules of the system.

OO 测试可能相当复杂。指标可以帮助您根据测量的特征将测试资源定位在“可疑”的线程、场景和类包上。第 23.3.3 节中提到的 OO 设计指标提供了设计质量的指示。它们还提供了运行面向对象系统所需的测试工作量的一般指示。

OO testing can be quite complex. Metrics can assist you in targeting testing resources at threads, scenarios, and packages of classes that are “suspect” based on measured characteristics. The OO design metrics noted in Section 23.3.3 provide an indication of design quality. They also provide a general indication of the amount of testing effort required to exercise an OO system.

Binder [Bin94b] 提出了一系列广泛的设计指标,这些指标对 OO 系统的“可测试性”有直接影响。这些指标考虑了封装和继承的各个方面。

Binder [Bin94b] suggests a broad array of design metrics that have a direct influence on the “testability” of an OO system. The metrics consider aspects of encapsulation and inheritance.

  • 方法缺乏凝聚力 (LCOM)。11 LCOM 的值越高,必须测试的状态就越多,以确保方法不会产生副作用。

  • Lack of cohesion in methods (LCOM).11 The higher the value of LCOM, the more states must be tested to ensure that methods do not generate side effects.

  • 公共和受保护的百分比 (PAP)。公共属性是从其他类继承的,因此对这些类是可见的。子类中的方法可以访问受保护的属性。该指标表示公共或受保护的类属性的百分比。PAP 的高值会增加类之间产生副作用的可能性,因为公共属性和受保护属性会导致耦合的可能性很高。12测试的设计必须确保此类副作用能够被发现。

  • Percent public and protected (PAP). Public attributes are inherited from other classes and therefore are visible to those classes. Protected attributes are accessible to methods in subclasses. This metric indicates the percentage of class attributes that are public or protected. High values for PAP increase the likelihood of side effects among classes because public and protected attributes lead to high potential for coupling.12 Tests must be designed to ensure that such side effects are uncovered.

  • 对数据成员 (PAD) 的公共访问。该指标表示可以访问另一个类的属性的类(或方法)的数量,这违反了封装性。PAD 值过高可能会导致不同类别之间产生副作用。测试的设计必须确保发现此类副作用。

  • Public access to data members (PAD). This metric indicates the number of classes (or methods) that can access another class’s attributes, a violation of encapsulation. High values for PAD lead to the potential for side effects among classes. Tests must be designed to ensure that such side effects are uncovered.

  • 根类数量 (NOR)。该指标是设计模型中描述的不同类层次结构的计数。必须为每个根类和相应的类层次结构开发测试套件。随着 NOR 的增加,测试工作量也会增加。

  • Number of root classes (NOR). This metric is a count of the distinct class hierarchies that are described in the design model. Test suites for each root class and the corresponding class hierarchy must be developed. As NOR increases, testing effort also increases.

  • 扇入 (FIN)。当在 OO 上下文中使用时,继承层次结构中的扇入表示多重继承。FIN > 1 表示一个类从多个根类继承其属性和操作。应尽可能避免 FIN > 1。

  • Fan-in (FIN). When used in the OO context, fan-in in the inheritance hierarchy is an indication of multiple inheritance. FIN > 1 indicates that a class inherits its attributes and operations from more than one root class. FIN > 1 should be avoided when possible.

  • 子代数量 (NOC) 和继承树深度 (DIT)。13正如我们在第 18 章中提到的,必须为每个子类重新测试超类方法。

  • Number of children (NOC) and depth of the inheritance tree (DIT).13 As we mentioned in Chapter 18, superclass methods will have to be retested for each subclass.

第476页

Page 476

23.5 维护指标

23.5 Metrics for Maintenance

本章介绍的所有软件度量均可用于新软件的开发和现有软件的维护。然而,已经提出了专门为维护活动设计的指标。

All the software metrics introduced in this chapter can be used for the development of new software and the maintenance of existing software. However, metrics designed explicitly for maintenance activities have been proposed.

IEEE 标准。982.1-2005 [IEE05] 建议采用软件成熟度指数(SMI),该指数可指示软件产品的稳定性(基于产品每个版本发生的更改)。确定以下信息:

IEEE Std. 982.1-2005 [IEE05] suggests a software maturity index (SMI) that provides an indication of the stability of a software product (based on changes that occur for each release of the product). The following information is determined:

M T = 当前版本中的模块数量

MT = number of modules in the current release

F c = 当前版本中已更改的模块数量

Fc = number of modules in the current release that have been changed

F a = 当前版本中已添加的模块数量

Fa = number of modules in the current release that have been added

F d = 在当前版本中删除的先前版本中的模块数量

Fd = number of modules from the preceding release that were deleted in the current release

软件成熟度指数按以下方式计算:

The software maturity index is computed in the following manner:

随着 SMI 接近 1.0,产品开始稳定。SMI 还可以用作规划软件维护活动的指标。生成软件产品版本的平均时间可以与 SMI 相关联,并且可以开发维护工作的经验模型。

As SMI approaches 1.0, the product begins to stabilize. SMI may also be used as a metric for planning software maintenance activities. The mean time to produce a release of a software product can be correlated with SMI, and empirical models for maintenance effort can be developed.

23.6 过程和项目指标

23.6 Process and Project Metrics

流程指标是跨所有项目并在很长一段时间内收集的。他们的目的是提供一组导致长期软件过程改进的过程指标(第 28 章)。项目指标使软件项目经理能够 (1) 评估正在进行的项目的状态,(2) 跟踪潜在风险,(3) 在问题领域变得“严重”之前发现问题,(4) 调整工作流程或任务,以及( 5)评估项目团队控制软件工作产品质量的能力。

Process metrics are collected across all projects and over long periods of time. Their intent is to provide a set of process indicators that lead to long-term software process improvement (Chapter 28). Project metrics enable a software project manager to (1) assess the status of an ongoing project, (2) track potential risks, (3) uncover problem areas before they go “critical,” (4) adjust work flow or tasks, and (5) evaluate the project team’s ability to control quality of software work products.

项目团队收集并转换为项目期间使用的指标的度量也可以传输给负责软件过程改进的人员。因此,流程域和项目域中都使用了许多相同的度量标准。

Measures that are collected by a project team and converted into metrics for use during a project can also be transmitted to those with responsibility for software process improvement. For this reason, many of the same metrics are used in both the process and project domains.

与用于战略目的的软件过程度量不同,软件项目度量是战术性的。也就是说,项目经理和软件团队使用项目度量和从中派生的指标来调整项目工作流程和技术活动。

Unlike software process metrics that are used for strategic purposes, software project measures are tactical. That is, project metrics and the indicators derived from them are used by a project manager and a software team to adapt project work flow and technical activities.

改进任何流程的唯一合理方法是衡量流程的特定属性,根据这些属性制定一组有意义的度量标准,然后使用这些度量标准提供将导致改进策略的指标(第28章。但在我们讨论软件度量及其对软件过程改进的影响之前,需要注意的是,过程只是众多“提高软件质量和组织绩效的可控因素”之一[Pau94]。第477页

The only rational way to improve any process is to measure specific attributes of the process, develop a set of meaningful metrics based on these attributes, and then use the metrics to provide indicators that will lead to a strategy for improvement (Chapter 28). But before we discuss software metrics and their impact on software process improvement, it is important to note that process is only one of a number of “controllable factors in improving software quality and organizational performance” [Pau94].Page 477

参考图 23.3,流程位于连接三个对软件质量和组织绩效有深远影响的因素的三角形的中心。人们的技能和动机已被证明 [Boe81] 是对质量和绩效影响最大的因素。产品的复杂性会对质量和团队绩效产生重大影响。填充流程的技术(即软件工程方法和工具)也会产生影响。

Referring to Figure 23.3, process sits at the center of a triangle connecting three factors that have a profound influence on software quality and organizational performance. The skill and motivation of people have been shown [Boe81] to be the most influential factors in quality and performance. The complexity of the product can have a substantial impact on quality and team performance. The technology (i.e., the software engineering methods and tools) that populates the process also has an impact.

23.3 软件质量和组织有效性的决定因素

Figure 23.3 Determinants for software quality and organizational effectiveness

此外,流程三角形存在于环境条件的圆圈内,包括开发环境(例如,集成软件工具)、业务条件(例如,截止日期、业务规则)和客户特征(例如,沟通和协作的便利性)。

In addition, the process triangle exists within a circle of environmental conditions that include the development environment (e.g., integrated software tools), business conditions (e.g., deadlines, business rules), and customer characteristics (e.g., ease of communication and collaboration).

您只能间接衡量软件流程的功效。也就是说,您可以根据从流程中得出的结果得出一组指标。结果包括对软件发布前发现的错误的衡量、交付给最终用户并由最终用户报告的缺陷、交付的工作产品(生产力)、消耗的人力、使用的日历时间、进度一致性和其他衡量标准。您还可以通过测量特定软件工程任务的特征来得出流程指标。例如,您可以衡量执行第 1 章中描述的总体活动和通用软件工程活动所花费的精力和时间。

You can only measure the efficacy of a software process indirectly. That is, you derive a set of metrics based on the outcomes that can be derived from the process. Outcomes include measures of errors uncovered before release of the software, defects delivered to and reported by end users, work products delivered (productivity), human effort expended, calendar time used, schedule conformance, and other measures. You can also derive process metrics by measuring the characteristics of specific software engineering tasks. For example, you might measure the effort and time spent performing the umbrella activities and the generic software engineering activities described in Chapter 1.

大多数软件项目中项目度量的首次应用发生在估算过程中。从过去的项目中收集的指标被用作对当前软件工作的工作量和时间进行估计的基础。随着项目的进展,所花费的工作量和日历时间的度量将与原始估计(和项目进度表)进行比较。项目经理使用这些数据来监视和控制进度。第478页

The first application of project metrics on most software projects occurs during estimation. Metrics collected from past projects are used as a basis from which effort and time estimates are made for current software work. As a project proceeds, measures of effort and calendar time expended are compared to original estimates (and the project schedule). The project manager uses these data to monitor and control progress.Page 478

随着技术工作的开始,其他项目指标开始变得重要。衡量以创建的模型、审查时间、功能点和交付的源代码行表示的生产率。此外,还会跟踪每个软件工程任务期间发现的错误。随着软件从需求发展到设计,收集技术指标来评估设计质量并提供影响代码生成和测试方法的指标。

As technical work commences, other project metrics begin to have significance. Production rates represented in terms of models created, review hours, function points, and delivered source lines are measured. In addition, errors uncovered during each software engineering task are tracked. As the software evolves from requirements into design, technical metrics are collected to assess design quality and to provide indicators that will influence the approach taken to code generation and testing.

项目指标的目的是双重的。首先,这些指标用于通过进行必要的调整来最大限度地缩短开发进度,以避免延迟并减轻潜在的问题和风险。其次,项目指标用于持续评估产品质量,并在必要时修改技术方法以提高质量。

The intent of project metrics is twofold. First, these metrics are used to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risks. Second, project metrics are used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality.

随着质量的提高,缺陷会最小化,并且随着缺陷数量的减少,项目期间所需的返工量也会减少。这导致总体项目成本的降低。

As quality improves, defects are minimized, and as the defect count goes down, the amount of rework required during the project is also reduced. This leads to a reduction in overall project cost.

当组织努力提高其流程成熟度的整体水平时,软件流程度量可以提供显着的好处。然而,与所有指标一样,这些指标可能会被滥用,造成的问题比解决的问题还要多。Grady [Gra92]提出了一种“软件度量礼仪”,该礼仪对于管理者和从业者来说都适用,因为他们制定了流程度量计划:

Software process metrics can provide significant benefits as an organization works to improve its overall level of process maturity. However, like all metrics, these can be misused, creating more problems than they solve. Grady [Gra92] suggests a “software metrics etiquette” that is appropriate for both managers and practitioners as they institute a process metrics program:

  • 解释指标数据时使用常识和组织敏感性。

  • Use common sense and organizational sensitivity when interpreting metrics data.

  • 定期向收集措施和指标的个人和团队提供反馈。

  • Provide regular feedback to the individuals and teams who collect measures and metrics.

  • 不要使用指标来评估个人。

  • Don’t use metrics to appraise individuals.

  • 与从业者和团队合作,设定用于实现这些目标的明确目标和指标。

  • Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.

  • 切勿使用指标来威胁个人或团队。

  • Never use metrics to threaten individuals or teams.

  • 表明问题领域的指标数据不应被视为“负面”。这些数据只是流程改进的指标。

  • Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement.

  • 不要过分关注单一指标而忽视其他重要指标。

  • Don’t obsess on a single metric to the exclusion of other important metrics.

随着组织对流程指标的收集和使用越来越熟悉,简单指标的推导就让位于更严格的方法,称为统计软件流程改进(SSPI)。本质上,SSPI 使用软件故障分析来收集有关在开发和使用应用程序、系统或产品时遇到的所有错误和缺陷14的信息。第479页

As an organization becomes more comfortable with the collection and use of process metrics, the derivation of simple indicators gives way to a more rigorous approach called statistical software process improvement (SSPI). In essence, SSPI uses software failure analysis to collect information about all errors and defects14 encountered as an application, system, or product is developed and used.Page 479

23.7 软件测量

23.7 Software Measurement

物理世界中的测量可以分为两种方式:直接测量(例如,螺栓的长度)和间接测量(例如,通过计数废品来测量所生产的螺栓的“质量”)。软件指标可以类似地分类。

Measurements in the physical world can be categorized in two ways: direct measures (e.g., the length of a bolt) and indirect measures (e.g., the “quality” of bolts produced, measured by counting rejects). Software metrics can be categorized similarly.

软件过程的直接衡量包括成本和工作量。产品的直接测量包括生成的代码行数 (LOC)、执行速度、内存大小以及在某个设定时间段内报告的缺陷。产品的间接衡量包括功能、质量、复杂性、效率、可靠性、可维护性以及第15 章讨论的许多其他“能力” 。第480页

Direct measures of the software process include cost and effort applied. Direct measures of the product include lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time. Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many other “–abilities” that are discussed in Chapter 15.Page 480

只要提前建立具体的测量约定,构建软件所需的成本和工作量、生成的代码行数以及其他直接测量值就相对容易收集。然而,软件的质量和功能或其效率或可维护性更难以评估,只能间接测量。

The cost and effort required to build software, the number of lines of code produced, and other direct measures are relatively easy to collect, as long as specific conventions for measurement are established in advance. However, the quality and functionality of software or its efficiency or maintainability are more difficult to assess and can be measured only indirectly.

我们将软件指标域划分为流程、项目和产品指标,并指出个人私有的产品指标通常会组合起来开发对软件团队公开的项目指标。然后整合项目指标以创建对整个软件组织公开的流程指标。但是组织如何结合来自不同个人或项目的指标呢?

We have partitioned the software metrics domain into process, project, and product metrics and noted that product metrics that are private to an individual are often combined to develop project metrics that are public to a software team. Project metrics are then consolidated to create process metrics that are public to the software organization as a whole. But how does an organization combine metrics that come from different individuals or projects?

为了说明这一点,请考虑一个简单的例子。两个不同项目团队的个人记录并分类他们在软件过程中发现的所有错误。然后将个人措施结合起来制定团队措施。A 团队在发布前的软件过程中发现了 342 个错误。B 队发现 184 个错误。在其他条件相同的情况下,哪个团队在发现整个过程中的错误方面更有效?因为您不知道项目的规模或复杂性,所以您无法回答这个问题。然而,如果这些衡量标准标准化,就可以创建能够与更广泛的组织平均值进行比较的软件指标。

To illustrate, consider a simple example. Individuals on two different project teams record and categorize all errors that they find during the software process. Individual measures are then combined to develop team measures. Team A found 342 errors during the software process prior to release. Team B found 184 errors. All other things being equal, which team is more effective in uncovering errors throughout the process? Because you do not know the size or complexity of the projects, you cannot answer this question. However, if the measures are normalized, it is possible to create software metrics that enable comparison to broader organizational averages.

面向规模的软件度量是通过考虑已生产的软件的规模来标准化质量和/或生产力度量而得出的。如果软件组织维护简单的记录,则可以创建一张面向规模的度量表,如图23.4所示。该表列出了过去几年已完成的每个软件开发项目以及该项目的相应措施。参考alpha项目的表条目(图 23.4 ) :经过 24 个人月的努力,开发了 12,100 行代码,成本为 168,000 美元。应该注意的是,表中记录的工作量和成本代表了所有软件工程活动(分析、设计、编码和测试),而不仅仅是编码。阿尔法项目的进一步信息表明,开发了 365 页文档,在软件发布前记录了 134 个错误,在向客户发布后的第一年运行中遇到了 29 个缺陷。三个人致力于 alpha 项目的软件开发。

Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced. If a software organization maintains simple records, a table of size-oriented measures, such as the one shown in Figure 23.4, can be created. The table lists each software development project that has been completed over the past few years and corresponding measures for that project. Referring to the table entry (Figure 23.4) for project alpha: 12,100 lines of code were developed with 24 person-months of effort at a cost of $168,000. It should be noted that the effort and cost recorded in the table represent all software engineering activities (analysis, design, code, and test), not just coding. Further information for project alpha indicates that 365 pages of documentation were developed, 134 errors were recorded before the software was released, and 29 defects were encountered after release to the customer within the first year of operation. Three people worked on the development of software for project alpha.

图23.4 面向规模的度量

Figure 23.4 Size-oriented metrics

要开发可与其他项目中的类似指标同化的指标,您可以选择代码行作为标准化值。根据表中包含的基本数据,可以为每个项目开发一组简单的面向规模的指标:第481页

To develop metrics that can be assimilated with similar metrics from other projects, you can choose lines of code as a normalization value. From the rudimentary data contained in the table, a set of simple size-oriented metrics can be developed for each project:Page 481

  • 每个 KLOC 的错误(千行代码)

  • Errors per KLOC (thousand lines of code)

  • 每个 KLOC 的缺陷

  • Defects per KLOC

  • 每 KLOC 美元

  • $ per KLOC

  • 每个 KLOC 的文档页数

  • Pages of documentation per KLOC

此外,还可以计算其他有趣的指标:

In addition, other interesting metrics can be computed:

  • 每人每月的错误数

  • Errors per person-month

  • KLOC 每人月

  • KLOC per person-month

  • 每页文档 $

  • $ per page of documentation

面向规模的度量标准并未被普遍接受为衡量软件过程的最佳方法。大多数争议都围绕着使用代码行数作为关键衡量标准。LOC 衡量标准的支持者声称,LOC 是所有软件开发项目的一个“工件”,可以轻松计算,许多现有的软件估算模型使用 LOC 或 KLOC 作为关键输入,并且大量文献和数据基于LOC 已经存在。另一方面,反对者认为 LOC 措施取决于编程语言,当考虑生产力时,它们会惩罚设计良好但较短的程序;它们不能轻易适应非过程语言;它们在估算中的使用需要一定程度的详细程度,而这可能很难实现(即,规划者必须在分析和设计完成之前很久就估算出要生成的 LOC)。

Size-oriented metrics are not universally accepted as the best way to measure the software process. Most of the controversy swirls around the use of lines of code as a key measure. Proponents of the LOC measure claim that LOC is an “artifact” of all software development projects that can be easily counted, that many existing software estimation models use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC already exists. On the other hand, opponents argue that LOC measures are programming language dependent, that when productivity is considered, they penalize well-designed but shorter programs; that they cannot easily accommodate nonprocedural languages; and that their use in estimation requires a level of detail that may be difficult to achieve (i.e., the planner must estimate the LOC to be produced long before analysis and design have been completed).

类似的争论,赞成和反对,可以用于面向功能的度量,例如功能点(FP)或用例点(两者都在第25 章中讨论)。面向功能的软件度量使用应用程序提供的功能度量作为标准化值。面向功能的度量的计算基于软件信息域和复杂性的特征。

Similar arguments, pro and con, can be made for function-oriented metrics such as function points (FP) or use case points (both are discussed in Chapter 25). Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value. Computation of a function-oriented metric is based on characteristics of the software’s information domain and complexity.

与 LOC 测量一样,功能点也是有争议的。支持者声称 FP 独立于编程语言,使其成为使用传统和非过程语言的应用程序的理想选择,并且它基于在项目发展早期更有可能已知的数据,使得 FP 作为估计更有吸引力方法。反对者声称该方法需要一些“花招”,因为计算是基于主观数据而不是客观数据,信息域(和其他维度)的计数可能很难在事后收集,并且 FP 没有直接的方法。物理意义——它只是一个数字。

The function point, like the LOC measure, is controversial. Proponents claim that FP is programming language–independent, making it ideal for applications using conventional and nonprocedural languages, and that it is based on data that are more likely to be known early in the evolution of a project, making FP more attractive as an estimation approach. Opponents claim that the method requires some “sleight of hand” in that computation is based on subjective rather than objective data, that counts of the information domain (and other dimensions) can be difficult to collect after the fact, and that FP has no direct physical meaning—it’s just a number.

人们发现,功能点和基于 LOC 的指标是软件开发工作量和成本的相对准确的预测指标。然而,要使用 LOC 和 FP 进行估计(第 25 章),必须建立信息的历史基线。随着时间的推移,正是这些历史数据让您判断特定指标对未来项目的价值。

Function points and LOC-based metrics have been found to be relatively accurate predictors of software development effort and cost. However, to use LOC and FP for estimation (Chapter 25), an historical baseline of information must be established. It is this historical data that over time will let you judge the value of a particular metric on future projects.

面向规模的衡量标准(例如,LOC)和面向功能的衡量标准通常用于得出生产力指标。这总是会引发关于此类数据使用的争论。一组的 LOC/人月(或 FP/人月)是否应该与另一组的类似数据进行比较?管理者是否应该使用这些指标来评估个人的绩效?这些问题的答案都是否定的!出现这种反应的原因是,影响生产力的因素有很多,导致“苹果和橙子”的比较很容易被误解。第482页

Size-oriented measures (e.g., LOC) and function-oriented measures are often used to derive productivity metrics. This invariably leads to a debate about the use of such data. Should the LOC/person-month (or FP/person-month) of one group be compared to similar data from another? Should managers appraise the performance of individuals by using these metrics? The answer to these questions is an emphatic no! The reason for this response is that many factors influence productivity, making for “apples and oranges” comparisons that can be easily misinterpreted.Page 482

在流程和项目指标的背景下,您应该主要关注生产力和质量——软件开发“输出”的衡量标准,作为所付出的努力和时间的函数,以及所生产的工作产品的“适用性”衡量标准。

Within the context of process and project metrics, you should be concerned primarily with productivity and quality—measures of software development “output” as a function of effort and time applied and measures of the “fitness for use” of the work products that are produced.

出于流程改进和项目规划的目的,您的兴趣是历史性的。过去项目的软件开发效率是多少?所生产的软件质量如何?如何将过去的生产力和质量数据推断到现在?它如何帮助我们改进流程并更准确地规划新项目?

For process improvement and project planning purposes, your interest is historical. What was software development productivity on past projects? What was the quality of the software that was produced? How can past productivity and quality data be extrapolated to the present? How can it help us improve the process and plan new projects more accurately?

23.8 软件质量的度量

23.8 Metrics for Software Quality

系统、应用程序或产品的质量取决于描述问题的需求、对解决方案建模的设计、生成可执行程序的代码以及运行软件以发现错误的测试。软件是一个复杂的实体。因此,在开发工作产品时,可能会出现错误。流程指标旨在改进软件流程,以便以最有效的方式发现错误。

The quality of a system, application, or product is only as good as the requirements that describe the problem, the design that models the solution, the code that leads to an executable program, and the tests that exercise the software to uncover errors. Software is a complex entity. Therefore, errors are to be expected as work products are developed. Process metrics are intended to improve the software process so that errors are uncovered in the most effective manner.

您可以使用测量来评估需求和设计模型、源代码以及在设计软件时创建的测试用例的质量。为了完成这种实时评估,您可以应用产品指标以客观而非主观的方式评估软件工程工作产品的质量。

You can use measurement to assess the quality of the requirements and design models, the source code, and the test cases that have been created as the software is engineered. To accomplish this real-time assessment, you apply product metrics to evaluate the quality of software engineering work products in objective rather than subjective ways.

项目经理还必须随着项目的进展评估质量。将各个软件工程师收集的私有指标组合起来以提供项目级结果。尽管可以收集许多质量度量,但项目级别的主要目的是度量错误和缺陷。从这些措施中得出的指标可以表明个人和团体软件质量保证和控制活动的有效性。

A project manager must also evaluate quality as the project progresses. Private metrics collected by individual software engineers are combined to provide project-level results. Although many quality measures can be collected, the primary thrust at the project level is to measure errors and defects. Metrics derived from these measures provide an indication of the effectiveness of individual and group software quality assurance and control activities.

每个功能点的工作产品错误、每个审核小时发现的错误以及每个测试小时发现的错误等指标可以深入了解该指标所暗示的每个活动的有效性。错误数据还可用于计算每个流程框架活动的缺陷去除效率(DRE)。本节稍后将讨论 DRE。

Metrics such as work product errors per function point, errors uncovered per review hour, and errors uncovered per testing hour provide insight into the efficacy of each of the activities implied by the metric. Error data can also be used to compute the defect removal efficiency (DRE) for each process framework activity. DRE is discussed later in this section.

尽管软件质量有很多衡量标准,但正确性、可维护性、完整性和可用性为项目团队提供了有用的指标。Gilb [Gil88]提出了每个的定义和衡量标准。

Although there are many measures of software quality, correctness, maintainability, integrity, and usability provide useful indicators for the project team. Gilb [Gil88] suggests definitions and measures for each.

  • 正确性。正确性是指软件执行其所需功能的程度。缺陷(缺乏正确性)是程序发布供一般使用后程序用户报告的那些问题。出于质量评估的目的,缺陷在标准时间段(通常为一年)内进行计数。最常见的正确性衡量标准是 KLOC 中的缺陷,其中缺陷被定义为经验证不符合要求。第483页

  • Correctness. Correctness is the degree to which the software performs its required function. Defects (lack of correctness) are those problems reported by a user of the program after the program has been released for general use. For quality assessment purposes, defects are counted over a standard period of time, typically one year. The most common measure for correctness is defects per KLOC, where a defect is defined as a verified lack of conformance to requirements.Page 483

  • 可维护性。可维护性是指在遇到错误时可以更正程序,在环境发生变化时进行调整,或者在客户希望需求发生变化时进行增强的容易程度。没有办法直接衡量可维护性;因此,我们必须采取间接措施。一个简单的面向时间的指标是平均变更时间(MTTC),即分析变更请求、设计适当的修改、实施变更、测试变更并将变更分发给所有用户所需的时间。

  • Maintainability. Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements. There is no way to measure maintainability directly; therefore, we must use indirect measures. A simple time-oriented metric is mean time to change (MTTC), the time it takes to analyze the change request, design an appropriate modification, implement the change, test it, and distribute the change to all users.

  • 正直。该属性衡量系统抵御对其安全性的攻击(意外和故意)的能力。为了衡量完整性,必须定义两个附加属性:威胁和安全。威胁是在给定时间内发生特定类型攻击的概率(可以估计或从经验证据得出)。安全性是特定类型的攻击被击退的概率(可以估计或从经验证据得出)。系统的完整性可以定义为:

    完整性 = Σ[1 − (威胁 × (1 − 安全))]

  • Integrity. This attribute measures a system’s ability to withstand attacks (both accidental and intentional) to its security. To measure integrity, two additional attributes must be defined: threat and security. Threat is the probability (which can be estimated or derived from empirical evidence) that an attack of a specific type will occur within a given time. Security is the probability (which can be estimated or derived from empirical evidence) that the attack of a specific type will be repelled. The integrity of a system can then be defined as:

    Integrity = Σ[1 − (threat × (1 − security))]

  • 例如,如果威胁(发生攻击的概率)为 0.25,安全性(击退攻击的可能性)为 0.95,则系统的完整性为 0.99(非常高)。另一方面,如果威胁概率为 0.50,而击退攻击的可能性仅为 0.25,则系统的完整性为 0.63(低得令人无法接受)。

  • For example, if threat (the probability that an attack will occur) is 0.25 and security (the likelihood of repelling an attack) is 0.95, the integrity of the system is 0.99 (very high). If, on the other hand, the threat probability is 0.50 and the likelihood of repelling an attack is only 0.25, the integrity of the system is 0.63 (unacceptably low).

  • 可用性。可用性是量化易用性的一种尝试,可以根据第 12 章中介绍的特征来衡量。

  • Usability. Usability is an attempt to quantify ease of use and can be measured in terms of the characteristics presented in Chapter 12.

这四个因素只是被提议作为软件质量衡量标准的一部分。

These four factors are only a sampling of those that have been proposed as measures for software quality.

在项目和流程层面提供效益的质量指标是缺陷去除效率(DRE)。从本质上讲,DRE 是对质量保证和控制措施的过滤能力的衡量,因为它们应用于所有流程框架活动。

A quality metric that provides benefit at both the project and process level is defect removal efficiency (DRE). In essence, DRE is a measure of the filtering ability of quality assurance and control actions as they are applied throughout all process framework activities.

当考虑整个项目时,DRE 的定义如下:

When considered for a project as a whole, DRE is defined in the following manner:

其中E是在将软件交付给最终用户之前发现的错误数量,D是交付之后发现的缺陷数量。

where E is the number of errors found before delivery of the software to the end user and D is the number of defects found after delivery.

DRE 的理想值为 1。即软件中没有发现任何缺陷。实际上,D将大于 0,但 DRE 的值仍然可以接近 1。随着E 的增加(对于D的给定值),DRE 的总体值开始接近 1。事实上,随着E 的增加,它是D的最终值可能会减小(错误在成为缺陷之前被过滤掉)。如果用作提供质量控制和保证活动过滤能力的指标,DRE 鼓励软件项目团队制定在交付前发现尽可能多错误的技术。

The ideal value for DRE is 1. That is, no defects are found in the software. Realistically, D will be greater than 0, but the value of DRE can still approach 1. As E increases (for a given value of D), the overall value of DRE begins to approach 1. In fact, as E increases, it is likely that the final value of D will decrease (errors are filtered out before they become defects). If used as a metric that provides an indicator of the filtering ability of quality control and assurance activities, DRE encourages a software project team to institute techniques for finding as many errors as possible before delivery.

第484页DRE 还可以在项目中用于评估团队在将错误传递到下一个框架活动或软件工程任务之前发现错误的能力。例如,需求分析生成一个需求模型,可以对其进行审查以发现并纠正错误。在审查需求模型期间未发现的那些错误将传递到设计(可能会或可能不会发现)。当在这种情况下使用时,我们将 DRE 重新定义为

Page 484DRE can also be used within the project to assess a team’s ability to find errors before they are passed to the next framework activity or software engineering task. For example, requirements analysis produces a requirements model that can be reviewed to find and correct errors. Those errors that are not found during the review of the requirements model are passed on to design (where they may or may not be found). When used in this context, we redefine DRE as

其中E i是在软件工程操作i期间发现的错误数量,E i + 1是在软件工程操作i + 1期间发现的错误数量,这些错误可追溯到软件工程操作i中未发现的错误。

where Ei is the number of errors found during software engineering action i and Ei + 1 is the number of errors found during software engineering action i + 1 that are traceable to errors that were not discovered in software engineering action i.

软件团队(或单个软件工程师)的质量目标是实现接近 1 的DRE i 。也就是说,错误应该在传递到下一个活动或操作之前被过滤掉。如果在进行分析和设计时 DRE 较低,请花一些时间改进进行正式技术审查的方式。

A quality objective for a software team (or an individual software engineer) is to achieve a DREi that approaches 1. That is, errors should be filtered out before they are passed on to the next activity or action. If DRE is low as you move through analysis and design, spend some time improving the way you conduct formal technical reviews.

第485页

Page 485

23.9 建立软件度量程序

23.9 Establishing Software Metrics Programs

软件工程学院开发了一本全面的指南 [Par96b],用于建立“目标驱动”的软件指标计划。该指南建议执行以下步骤:(1) 确定您的业务目标,(2) 确定您想了解或学习的内容,(3) 确定您的子目标,(4) 确定与您的子目标相关的实体和属性,(5)正式确定您的衡量目标,(6) 确定可量化的问题和用于帮助您实现衡量目标的相关指标,(7) 确定您将收集用于构建指标的数据元素,(8) 确定衡量指标的措施使用这些定义,并使这些定义具有可操作性,(9) 确定为实施这些措施而将采取的行动,以及 (10) 制定实施这些措施的计划。这些步骤的详细讨论最好留给 SEI 的指南。然而,以下示例对关键点进行了简要概述。

The Software Engineering Institute has developed a comprehensive guidebook [Par96b] for establishing a “goal-driven” software metrics program. The guidebook suggests the following steps: (1) identify your business goals, (2) identify what you want to know or learn, (3) identify your subgoals, (4) identify the entities and attributes related to your subgoals, (5) formalize your measurement goals, (6) identify quantifiable questions and the related indicators that you will use to help you achieve your measurement goals, (7) identify the data elements that you will collect to construct the indicators, (8) identify the measures to be used, and make these definitions operational, (9) identify the actions that you will take to implement the measures, and (10) prepare a plan for implementing the measures. A detailed discussion of these steps is best left to the SEI’s guidebook. However, a brief overview of key points is illustrated by the following example.

因为软件支持业务功能,区分基于计算机的系统或产品,或者本身充当产品,所以为业务定义的目标几乎总是可以追溯到软件工程级别的特定目标。例如,考虑SafeHome产品。软件工程和业务经理作为一个团队,制定了一系列优先业务目标:

Because software supports business functions, differentiates computer-based systems or products, or acts as a product in itself, goals defined for the business can almost always be traced downward to specific goals at the software engineering level. For example, consider the SafeHome product. Working as a team, software engineering and business managers develop a list of prioritized business goals:

  1. 提高客户对我们产品的满意度。

  2. Improve our customers’ satisfaction with our products.

  3. 让我们的产品更容易使用。

  4. Make our products easier to use.

  5. 缩短我们将新产品推向市场所需的时间。

  6. Reduce the time it takes us to get a new product to market.

  7. 使对我们产品的支持变得更加容易。

  8. Make support for our products easier.

  9. 提高我们的整体盈利能力。

  10. Improve our overall profitability.

软件组织检查每个业务目标并询问:“我们管理、执行或支持哪些活动,以及我们希望在这些活动中改进哪些内容?” 为了回答这些问题,SEI 建议创建一个“实体问题列表”,其中记录了软件过程中受软件组织管理或影响的所有事物(实体)。实体的示例包括开发资源、工作产品、源代码、测试用例、变更请求、软件工程任务和时间表。对于列出的每个实体,软件人员会提出一组问题来评估该实体的定量特征(例如,规模、成本、开发时间)。作为创建实体问题列表的结果而导出的问题导致导出一组子目标,这些子目标与作为软件过程的一部分创建的实体和执行的活动直接相关。

The software organization examines each business goal and asks: “What activities do we manage, execute, or support and what do we want to improve within these activities?” To answer these questions, the SEI recommends the creation of an “entity-question list” in which all things (entities) within the software process that are managed or influenced by the software organization are noted. Examples of entities include development resources, work products, source code, test cases, change requests, software engineering tasks, and schedules. For each entity listed, software people develop a set of questions that assess quantitative characteristics of the entity (e.g., size, cost, time to develop). The questions derived as a consequence of the creation of an entity-question list lead to the derivation of a set of subgoals that relate directly to the entities created and the activities performed as part of the software process.

考虑第四个目标:“让对我们产品的支持变得更容易。” 为此目标可能会衍生出以下问题列表 [Par96b]:

Consider the fourth goal: “Make support for our products easier.” The following list of questions might be derived for this goal [Par96b]:

  • 客户变更请求是否包含我们充分评估变更并及时实施变更所需的信息?

  • Do customer change requests contain the information we require to adequately evaluate the change and then implement it in a timely manner?

  • 变更请求积压有多大?

  • How large is the change request backlog?

  • 根据客户需求,我们修复错误的响应时间是否可以接受?

  • Is our response time for fixing bugs acceptable based on customer need?

  • 我们的变更控制流程(第 22 章)是否得到遵循?

  • Is our change control process (Chapter 22) followed?

  • 高优先级的变更是否及时实施?

  • Are high-priority changes implemented in a timely manner?

第486页基于这些问题,软件组织可以得出以下子目标:提高变更管理流程的性能。识别与子目标相关的软件过程实体和属性,并描述与它们相关的测量目标。

Page 486Based on these questions, the software organization can derive the following subgoal: Improve the performance of the change management process. The software process entities and attributes that are relevant to the subgoal are identified, and the measurement goals associated with them are delineated.

SEI [Par96b] 为其目标驱动测量方法的步骤 6 到 10 提供了详细指导。本质上,您将测量目标细化为问题,这些问题进一步细化为实体和属性,然后细化为指标。

The SEI [Par96b] provides detailed guidance for steps 6 through 10 of its goal-driven measurement approach. In essence, you refine measurement goals into questions that are further refined into entities and attributes that are then refined into metrics.

绝大多数软件开发组织的软件人员少于 20 人。期望此类组织开发全面的软件度量计划是不合理的,在大多数情况下也是不现实的。然而,有理由建议各种规模的软件组织15进行测量,然后使用所得指标来帮助改进其本地软件流程以及其生产的产品的质量和及时性。

The vast majority of software development organizations have fewer than 20 software people. It is unreasonable, and in most cases unrealistic, to expect that such organizations will develop comprehensive software metrics programs. However, it is reasonable to suggest that software organizations15 of all sizes measure and then use the resultant metrics to help improve their local software process and the quality and timeliness of the products they produce.

小型组织可以从关注结果而不是衡量开始。软件团队接受调查以确定需要改进的单一目标。例如,“减少评估和实施变更请求的时间。” 小型组织可能会选择以下一组易于收集的度量:

A small organization can begin by focusing not on measurement but rather on results. The software group is polled to define a single objective that requires improvement. For example, “reduce the time to evaluate and implement change requests.” A small organization might select the following set of easily collected measures:

  • 从发出请求到评估完成所经过的时间(小时或天),t队列

  • Time (hours or days) elapsed from the time a request is made until evaluation is complete, tqueue.

  • 执行评估的工作量(人-小时),W eval

  • Effort (person-hours) to perform the evaluation, Weval.

  • 从完成评估到将变更单分配给人员所用的时间(小时或天),t eval

  • Time (hours or days) elapsed from completion of evaluation to assignment of change order to personnel, teval.

  • 做出改变所需的努力(人-小时),W改变

  • Effort (person-hours) required to make the change, Wchange.

  • 进行更改所需的时间(小时或天)t更改

  • Time required (hours or days) to make the change, tchange.

  • 在工作中发现的错误进行更改,E更改

  • Errors uncovered during work to make change, Echange.

  • 向客户群发布变更后发现的缺陷,D变更

  • Defects uncovered after change is released to the customer base, Dchange.

一旦收集了多个变更请求的这些度量值,就可以计算从变更请求到变更实施的总耗用时间以及初始排队、评估和变更分配以及变更实施所占用的耗用时间的百分比。同样,可以确定评估和实施所需的工作百分比。这些指标可以在质量数据、 E变更D变更的背景下进行评估。这些百分比可以洞察变更请求流程在何处变慢,并可能导致流程改进步骤以减少t队列W evalt evalW变更和/或E变更。此外,缺陷去除效率可以计算为

Once these measures have been collected for a number of change requests, it is possible to compute the total elapsed time from change request to implementation of the change and the percentage of elapsed time absorbed by initial queuing, evaluation and change assignment, and change implementation. Similarly, the percentage of effort required for evaluation and implementation can be determined. These metrics can be assessed in the context of quality data, Echange and Dchange. The percentages provide insight into where the change request process slows down and may lead to process improvement steps to reduce tqueue, Weval, teval, Wchange, and/or Echange. In addition, the defect removal efficiency can be computed as

DRE 可以与经过的时间和总工作量进行比较,以确定质量保证活动对进行变更所需的时间和工作量的影响。

DRE can be compared to elapsed time and total effort to determine the impact of quality assurance activities on the time and effort required to make a change.

第487页大多数软件开发人员仍然不进行测量,而且遗憾的是,大多数人都没有开始测量的意愿。正如我们在本章前面提到的,问题在于文化。试图收集过去未曾采取过的措施往往会引发抵制。“我们为什么需要这样做?” 一位忙碌的项目经理问道。“我不明白这有什么意义,”一位过度劳累的从业者抱怨道。为什么衡量软件工程的过程及其产生的产品(软件)如此重要?答案是比较明显的。如果你不衡量,就没有真正的方法来确定你是否在进步。如果你没有进步,你就会迷失。

Page 487The majority of software developers still do not measure, and sadly, most have little desire to begin. As we noted previously in this chapter, the problem is cultural. Attempting to collect measures where none have been collected in the past often precipitates resistance. “Why do we need to do this?” asks a harried project manager. “I don’t see the point,” complains an overworked practitioner. Why is it so important to measure the process of software engineering and the product (software) that it produces? The answer is relatively obvious. If you do not measure, there is no real way of determining whether you are improving. And if you are not improving, you are lost.

23.10 总结

23.10 Summary

测量使管理者和从业者能够改进软件过程;协助软件项目的规划、跟踪和控制;并评估所生产的产品(软件)的质量。过程、项目和产品的特定属性的度量用于计算软件指标。可以对这些指标进行分析,以提供指导管理和技术行动的指标。

Measurement enables managers and practitioners to improve the software process; assist in the planning, tracking, and control of software projects; and assess the quality of the product (software) that is produced. Measures of specific attributes of the process, project, and product are used to compute software metrics. These metrics can be analyzed to provide indicators that guide management and technical actions.

流程度量使组织能够通过深入了解软件流程的有效性来采取战略观点。项目指标是战术性的。它们使项目经理能够实时调整项目工作流程和技术方法。

Process metrics enable an organization to take a strategic view by providing insight into the effectiveness of a software process. Project metrics are tactical. They enable a project manager to adapt project work flow and technical approach in a real-time manner.

测量导致文化变革。数据收集、指标计算和指标分析是开始指标计划必须执行的三个步骤。一般来说,目标驱动的方法可以帮助组织专注于其业务的正确指标。

Measurement results in cultural change. Data collection, metrics computation, and metrics analysis are the three steps that must be implemented to begin a metrics program. In general, a goal-driven approach helps an organization focus on the right metrics for its business.

整个行业都使用以尺寸和功能为导向的指标。面向规模的指标使用代码行作为其他指标(例如人月或缺陷)的标准化因素。很少有产品指标被提议直接用于软件测试和维护。然而,许多其他产品指标可用于指导测试过程并作为评估计算机程序可维护性的机制。

Both size- and function-oriented metrics are used throughout the industry. Size-oriented metrics use the line of code as a normalizing factor for other measures such as person-months or defects. Few product metrics have been proposed for direct use in software testing and maintenance. However, many other product metrics can be used to guide the testing process and as a mechanism for assessing the maintainability of a computer program.

软件指标提供了一种评估内部产品属性质量的定量方法,从而使您能够在产品构建之前评估质量。指标提供了创建有效的需求和设计模型、可靠的代码和彻底的测试所需的洞察力。

Software metrics provide a quantitative way to assess the quality of internal product attributes, thereby enabling you to assess quality before the product is built. Metrics provide the insight necessary to create effective requirements and design models, solid code, and thorough tests.

软件质量指标,如生产力指标,重点关注流程、项目和产品。通过开发和分析质量指标基线,组织可以纠正软件过程中导致软件缺陷的区域。

Software quality metrics, like productivity metrics, focus on the process, the project, and the product. By developing and analyzing a metrics baseline for quality, an organization can correct those areas of the software process that are the cause of software defects.

为了在现实环境中发挥作用,软件指标必须简单、可计算、有说服力、一致且客观。它应该独立于编程语言,并为您提供有效的反馈。

To be useful in a real-world context, a software metric must be simple and computable, persuasive, consistent, and objective. It should be programming language independent and provide you with effective feedback.

问题与思考点

Problems and Points to Ponder

23.1。System X 的软件有 24 个单独的功能需求和 14 个非功能需求。要求的特殊性是什么?完整性?

23.1. Software for System X has 24 individual functional requirements and 14 nonfunctional requirements. What is the specificity of the requirements? The completeness?

23.2. 一个主要的信息系统有1140个模块。有96个模块执行控制和协调功能,490个模块的功能取决于预先处理。该系统处理大约 220 个数据对象,每个数据对象平均具有三个属性。有 140 个独特的数据库项目和 90 个不同的数据库段。最后,600 个模块具有单一入口和出口点。计算该系统的 DSQI。第488页

23.2. A major information system has 1140 modules. There are 96 modules that perform control and coordination functions and 490 modules whose function depends on prior processing. The system processes approximately 220 data objects that each has an average of three attributes. There are 140 unique database items and 90 different database segments. Finally, 600 modules have single entry and exit points. Compute the DSQI for this system.Page 488

23.3。X类有 12 个操作。OO系统中所有操作的循环复杂度均已计算,模块复杂度的平均值为4。对于X类,操作1至12的复杂度为5,4,3,3,6,8,2,2 、 5、 5、 4、 4 分别。计算每个类的加权方法。

23.3. A class X has 12 operations. Cyclomatic complexity has been computed for all operations in the OO system, and the average value of module complexity is 4. For class X, the complexity for operations 1 to 12 is 5, 4, 3, 3, 6, 8, 2, 2, 5, 5, 4, 4, respectively. Compute the weighted methods per class.

23.4。遗留系统有 940 个模块。最新版本要求更改其中 90 个模块。此外,还添加了40个新模块,删除了12个旧模块。计算系统的软件成熟度指数。

23.4. A legacy system has 940 modules. The latest release required that 90 of these modules be changed. In addition, 40 new modules were added and 12 old modules were removed. Compute the software maturity index for the system.

23.5。为什么某些软件指标应该保持“私有”?提供应该保密的三个指标的示例。提供应该公开的三个指标的示例。

23.5. Why should some software metrics be kept “private”? Provide examples of three metrics that should be private. Provide examples of three metrics that should be public.

23.6。A 团队在发布前的软件工程过程中发现了 342 个错误。B 队发现 184 个错误。需要对项目 A 和 B 采取哪些额外措施来确定哪个团队更有效地消除错误?您会提出哪些指标来帮助做出决定?哪些历史数据可能有用?

23.6. Team A found 342 errors during the software engineering process prior to release. Team B found 184 errors. What additional measures would have to be made for projects A and B to determine which of the teams eliminated errors more efficiently? What metrics would you propose to help in making the determination? What historical data might be useful?

23.7。Web 工程团队构建了一个包含 145 个单独页面的电子商务 WebApp。其中 65 个页面是动态的;也就是说,它们是根据最终用户输入在内部生成的。该应用程序的定制索引是多少?

23.7. A Web engineering team has built an e-commerce WebApp that contains 145 individual pages. Of these pages, 65 are dynamic; that is, they are internally generated based on end-user input. What is the customization index for this application?

23.8。WebApp 及其支持环境尚未完全防御攻击。Web 工程师估计,抵御攻击的可能性只有 30%。该系统不包含敏感或有争议的信息,因此威胁概率为 25%。WebApp 的完整性如何?

23.8. A WebApp and its support environment have not been fully fortified against attack. Web engineers estimate that the likelihood of repelling an attack is only 30 percent. The system does not contain sensitive or controversial information, so the threat probability is 25 percent. What is the integrity of the WebApp?

23.9。在项目结束时,已确定在建模阶段发现了 30 个错误,在施工阶段发现了 12 个错误,这些错误可追溯到建模阶段未发现的错误。这两个阶段的 DRE 是什么?

23.9. At the conclusion of a project, it has been determined that 30 errors were found during the modeling phase and 12 errors were found during the construction phase that were traceable to errors not discovered in the modeling phase. What is the DRE for these two phases?

23.10。软件团队向最终用户提供软件增量。用户在使用的第一个月就发现了八个缺陷。在交付之前,软件团队在正式技术审查和所有测试任务中发现了 242 个错误。使用 1 个月后项目的总体 DRE 是多少?

23.10. A software team delivers a software increment to end users. The users uncover eight defects during the first month of use. Prior to delivery, the software team found 242 errors during formal technical reviews and all testing tasks. What is the overall DRE for the project after 1 month’s usage?

1本书的附录 2 包含针对软件工程师的数据科学介绍。

1 Appendix 2 in the book contains an introduction to data science geared toward software engineers.

2虽然对特定指标的批评在文献中很常见,但许多批评都集中在深奥的问题上,而忽略了指标在现实世界中的主要目标:帮助软件工程师建立系统和客观的方法来深入了解他们的工作并改进产品质量结果。

2 Although criticism of specific metrics is common in the literature, many critiques focus on esoteric issues and miss the primary objective of metrics in the real world: to help software engineers establish a systematic and objective way to gain insight into their work and to improve product quality as a result.

3 扇出定义为直接从属于模块I 的模块数量,即由模块 i 直接调用的模块数量

3 Fan-out is defined as the number of modules immediately subordinate to module I, that is, the number of modules that are directly invoked by module i.

4 Harrison、Counsell 和 Nithi [Har98b] 提出了一套替代的 OO 度量标准。敦促有兴趣的读者检查他们的作品。

4 An alternative suite of OO metrics has been proposed by Harrison, Counsell, and Nithi [Har98b]. Interested readers are urged to examine their work.

5 Chidamber 和 Kemerer 使用术语“方法”而不是“操作”。他们对该术语的使用反映在本节中。

5 Chidamber and Kemerer use the term methods rather than operations. Their usage of the term is reflected in this section.

6如果 CRC 索引卡是手动开发的,则必须先评估完整性和一致性,然后才能可靠地确定 CBO。

6 If CRC index cards are developed manually, completeness and consistency must be assessed before CBO can be determined reliably.

7正式定义有点复杂。详细信息请参见[Chi94]。

7 The formal definition is a bit more complex. See [Chi94] for details.

8 LCOM 指标在某些情况下提供了有用的见解,但在其他情况下可能会产生误导。例如,将耦合封装在类中可以增加整个系统的内聚力。因此,至少在一个重要的意义上,较高的 LCOM 实际上表明一个类可能具有较高的内聚力,而不是较低。

8 The LCOM metric provides useful insight in some situations, but it can be misleading in others. For example, keeping coupling encapsulated within a class increases the cohesion of the system as a whole. Therefore, in at least one important sense, higher LCOM actually suggests that a class may have higher cohesion, not lower.

9独特区域是布局显示内的一个区域,其完成一些特定的相关功能集(例如,菜单栏、静态图形显示、内容区域、动画显示)。

9 A distinct region is an area within the layout display that accomplishes some specific set of related functions (e.g., a menu bar, a static graphical display, a content area, an animated display).

10值得注意的是,霍尔斯特德的“定律”引起了很大的争议,许多人认为其基本理论存在缺陷。然而,已经对选定的编程语言进行了实验验证(例如,[Fel89])。

10 It should be noted that Halstead’s “laws” have generated substantial controversy, and many believe that the underlying theory has flaws. However, experimental verification for selected programming languages has been performed (e.g., [Fel89]).

11 LCOM 的描述见第 23.3.3 节。

11 See Section 23.3.3 for a description of LCOM.

12有些人提倡没有任何属性是公共或私有的,即 PAP = 0。这意味着所有属性必须通过方法在其他类中访问。

12 Some people promote designs with none of the attributes being public or private, that is, PAP = 0. This implies that all attributes must be accessed in other classes via methods.

13 NOC 和 DIT 的描述见第 23.3.3 节。

13 See Section 23.3.3 for a description of NOC and DIT.

14在本书中,错误被定义为软件工程工作产品中在软件交付给最终用户之前发现的一些缺陷。缺陷是指交付给最终用户后发现缺陷。应该指出的是,其他人并没有做出这种区分。

14 In this book, an error is defined as some flaw in a software engineering work product that is uncovered before the software is delivered to the end user. A defect is a flaw that is uncovered after delivery to the end user. It should be noted that others do not make this distinction.

15该讨论同样与采用敏捷软件开发流程的软件团队相关(第 3 章)。

15 This discussion is equally relevant to software teams that have adopted an agile software development process (Chapter 3).

第489页

Page 489

部分 管理软件项目

PART Four Managing Software Projects

在《软件工程:从业者方法》的这一部分中,您将学习计划、组织、监视和控制软件项目所需的管理技术。这些问题将在以下章节中讨论:

In this part of Software Engineering: A Practitioner’s Approach, you’ll learn the management techniques required to plan, organize, monitor, and control software projects. These questions are addressed in the chapters that follow:

  • 在软件项目期间必须如何管理人员、流程和问题?

  • How must people, process, and problem be managed during a software project?

  • 如何使用软件度量来管理软件项目和软件流程?

  • How can software metrics be used to manage a software project and the software process?

  • 软件团队如何对工作量、成本和项目持续时间进行可靠的估计?

  • How does a software team generate reliable estimates of effort, cost, and project duration?

  • 可以使用哪些技术来系统地评估可能影响项目成功的风险?

  • What techniques can be used to systematically assess the risks that can have an impact on project success?

  • 软件项目经理如何选择软件工程工作任务集?

  • How does a software project manager select the set of software engineering work tasks?

  • 项目进度表是如何创建的?

  • How is a project schedule created?

  • 为什么维护和支持对于软件工程经理和从业者都如此重要?

  • Why are maintenance and support so important for both software engineering managers and practitioners?

一旦回答了这些问题,您就可以更好地准备管理软件项目,从而在可用资源的限制下及时交付高质量的产品。

Once these questions are answered, you’ll be better prepared to manage software projects in a way that will lead to timely delivery of a high-quality product constrained by the available resources.

第490页

Page 490

章节

chapter

24项目管理概念

24 Project Management Concepts

Meiler Page-Jones [Pag85] 在其关于软件项目管理的书的序言中评论了进展不顺利的软件项目,“我惊恐地看到... 。。经理们徒劳地挣扎着完成噩梦般的项目,在不可能的最后期限下挣扎,或者交付的系统激怒了用户,并继续消耗了大量的维护时间。”

In the preface to his book on software project management, Meiler Page-Jones [Pag85] comments on software projects that are not going well, “I’ve watched in horror as . . . managers futilely struggled through nightmarish projects, squirmed under impossible deadlines, or delivered systems that outraged their users and went on to devour huge chunks of maintenance time.”

第491页佩奇-琼斯描述的是一系列管理和技术问题导致的症状。然而,如果对每个项目进行事后分析,很可能会遇到一个一致的主题:项目管理薄弱或不存在。

Page 491What Page-Jones describes are symptoms that result from an array of management and technical problems. However, if a postmortem were to be conducted for every project, it is very likely that a consistent theme would be encountered: project management was weak or nonexistent.

在本章以及第 25 章到第 27 章中,我们将介绍实现有效软件项目管理的关键概念。本章讨论基本的软件项目管理概念和原则。第 25 章讨论了用于估算成本和创建切合实际(但灵活)的进度表的技术。第 26 章介绍了实现有效风险监控、缓解和管理的管理活动。第 27 章考虑产品支持问题并讨论在处理已部署系统的维护时会遇到的管理问题。最后,第 28 章讨论了研究和改进团队软件工程流程的技术。

In this chapter and Chapters 25 through 27, we’ll present the key concepts that lead to effective software project management. This chapter considers basic software project management concepts and principles. Chapter 25 discusses the techniques that are used to estimate costs and create realistic (but flexible) schedules. Chapter 26 presents the management activities that lead to effective risk monitoring, mitigation, and management. Chapter 27 considers product support concerns and discusses the management issues that you’ll encounter when dealing with maintenance of deployed systems. Finally, Chapter 28 discusses techniques for studying and improving your team’s software engineering processes.

24.1 管理范围

24.1 The Management Spectrum

有效的软件项目管理侧重于 4 个 P:人员、产品、流程和项目。该顺序不是任意的。忘记软件工程工作是一项高度人类努力的经理将永远不会在项目管理方面取得成功。如果管理者在产品发展的早期未能鼓励利益相关者进行全面的沟通,那么就有可能为错误的问题构建出优雅的解决方案。不太关注流程的管理者面临着将有效的技术方法和工具插入真空的风险。没有可靠计划就开始工作的经理会危及项目的成功。当变化出现时,没有准备好修改计划的管理者注定会失败。

Effective software project management focuses on the four Ps: people, product, process, and project. The order is not arbitrary. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management. A manager who fails to encourage comprehensive stakeholder communication early in the evolution of a product risks building an elegant solution for the wrong problem. The manager who pays little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum. The manager who begins work without a solid plan jeopardizes the success of the project. The manager who is not ready to revise the plan when changes arise is doomed to fail.

24.1.1 人民

24.1.1 The People

自 20 世纪 60 年代以来,人们一直在讨论培养积极主动、高技能的软件人才。事实上,“人的因素”是如此重要,以至于软件工程学院开发了人员能力成熟度模型(People-CMM),认识到“每个组织都需要不断提高其吸引、发展、激励人才的能力”这一事实。 、组织和保留实现其战略业务目标所需的劳动力”[Cur09]。

The cultivation of motivated, highly skilled software people has been discussed since the 1960s. In fact, the “people factor” is so important that the Software Engineering Institute has developed a People Capability Maturity Model (People-CMM), in recognition of the fact that “every organization needs to continually improve its ability to attract, develop, motivate, organize, and retain the workforce needed to accomplish its strategic business objectives” [Cur09].

人员能力成熟度模型定义了软件人员的以下关键实践领域:人员配置、沟通和协调、工作环境、绩效管理、培训、薪酬、能力分析和发展、职业发展、工作组发展、团队/文化发展等。实现高水平人员 CMM 成熟度的组织更有可能实施有效的软件项目管理实践。

The people capability maturity model defines the following key practice areas for software people: staffing, communication and coordination, work environment, performance management, training, compensation, competency analysis and development, career development, workgroup development, and team/culture development, and others. Organizations that achieve high levels of People-CMM maturity have a higher likelihood of implementing effective software project management practices.

24.1.2 产品

24.1.2 The Product

在规划项目之前,应确定产品目标和范围,考虑替代解决方案,并确定技术和管理限制。如果没有这些信息,就不可能定义合理(且准确)的成本估算、有效的风险评估、项目任务的实际分解或可提供有意义的进度指示的可管理的项目进度表。第492页

Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress.Page 492

作为软件开发人员,您和其他利益相关者必须会面来定义产品目标和范围。在许多情况下,此活动作为系统工程或业务流程工程的一部分开始,并继续作为软件需求工程的第一步(第 7 章)。目标确定产品的总体目标(从利益相关者的角度),而不考虑如何实现这些目标。这些通常采用用户故事和正式用例的形式。范围确定了表征产品的主要数据、功能和行为,更重要的是,试图以定量的方式限制这些特征。

As a software developer, you and other stakeholders must meet to define product objectives and scope. In many cases, this activity begins as part of the system engineering or business process engineering and continues as the first step in software requirements engineering (Chapter 7). Objectives identify the overall goals for the product (from the stakeholders’ points of view) without considering how these goals will be achieved. These often take the form of user stories and formal use cases. Scope identifies the primary data, functions, and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner.

一旦了解了产品目标和范围,就会考虑替代解决方案。尽管讨论的细节很少,但考虑到交付期限、预算限制、人员可用性、技术接口和无数其他因素所施加的限制,替代方案使管理者和从业者能够选择“最佳”方法。

Once the product objectives and scope are understood, alternative solutions are considered. Although very little detail is discussed, the alternatives enable managers and practitioners to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and myriad other factors.

24.1.3 过程

24.1.3 The Process

软件过程(第 2 章第 4章)提供了建立软件开发综合计划的框架。少数框架活动适用于所有软件项目,无论其规模或复杂程度如何。即使是敏捷开发人员也会遵循变化友好的流程(第 3 章),对他们的软件工程工作施加一些纪律。许多任务集(任务、里程碑、工作产品和质量保证点)使框架活动能够适应软件项目的特征和项目团队的要求。最后,伞式活动(例如软件质量保证、软件配置管理和测量)覆盖了过程模型。伞式活动独立于任何一项框架活动,并且发生在整个流程中。

A software process (Chapters 2 through 4) provides the framework from which a comprehensive plan for software development can be established. A small number of framework activities are applicable to all software projects, regardless of their size or complexity. Even agile developers follow a change-friendly process (Chapter 3) to impose some discipline on their software engineering work. A number of task sets—tasks, milestones, work products, and quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. Finally, umbrella activities—such as software quality assurance, software configuration management, and measurement—overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process.

24.1.4 项目

24.1.4 The Project

我们进行有计划和受控的软件项目有一个主要原因——这是管理复杂性的唯一已知方法。然而,软件团队仍然在苦苦挣扎。Capers Jones [Jon04] 在对 1998 年至 2004 年间 250 个大型软件项目的研究中发现,“大约 25 个项目被认为是成功的,因为它们实现了进度、成本和质量目标。大约 50 个项目的延误或超支率低于 35%,而大约 175 个项目经历了严重的延误和超支,或者在未完成的情况下被终止。” 尽管当今软件项目的成功率可能有所提高,但我们的项目失败率仍然远高于应有的水平。2

We conduct planned and controlled software projects for one primary reason—it is the only known way to manage complexity. And yet, software teams still struggle. In a study of 250 large software projects between 1998 and 2004, Capers Jones [Jon04] found that “about 25 were deemed successful in that they achieved their schedule, cost, and quality objectives. About 50 had delays or overruns below 35 percent, while about 175 experienced major delays and overruns, or were terminated without completion.” Although the success rate for present-day software projects may have improved somewhat, our project failure rate remains much higher than it should be.2

为了避免项目失败,软件项目经理和构建产品的软件工程师必须避免一系列常见的警告信号,了解导致良好项目管理的关键成功因素,并制定用于规划、监视和控制的常识性方法项目[Gha14]。这些问题中的每一个都在第 24.5 节和后续章节中讨论。

To avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring, and controlling the project [Gha14]. Each of these issues is discussed in Section 24.5 and in the chapters that follow.

第493页

Page 493

24.2 人

24.2 People

人们构建计算机软件,项目之所以成功,是因为训练有素、积极进取的人们把事情做好了。我们所有人,从高级工程副总裁到最低级的从业者,常常认为人们是理所当然的。经理们认为,人是第一位的,但他们的行动有时与他们的言论不符。在本节中,我们将研究参与软件过程的利益相关者以及他们组织执行有效软件工程的方式。

People build computer software, and projects succeed because well-trained, motivated people get things done. All of us, from senior engineering vice presidents to the lowliest practitioner, often take people for granted. Managers argue that people are primary, but their actions sometimes belie their words. In this section, we examine the stakeholders who participate in the software process and the manner in which they are organized to perform effective software engineering.

24.2.1 利益相关者

24.2.1 The Stakeholders

软件流程(以及每个软件项目)由利益相关者组成,这些利益相关者可以分为以下五个类别之一:

The software process (and every software project) is populated by stakeholders who can be categorized into one of five constituencies:

  1. 高级经理(产品负责人)定义通常对项目有重大影响的业务问题。

  2. Senior managers (product owners) who define the business issues that often have a significant influence on the project.

  3. 项目(技术)经理(Scrum 大师或团队领导)必须计划、激励、组织和协调从事软件工作的从业人员。

  4. Project (technical) managers (Scrum masters or team leads) who must plan, motivate, organize, and coordinate the practitioners who do software work.

  5. 提供设计产品或应用程序所需的技术技能的从业者。

  6. Practitioners who deliver the technical skills that are necessary to engineer a product or application.

  7. 指定要设计的软件的要求的客户以及对结果有外围兴趣的其他利益相关者。

  8. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.

  9. 软件发布用于生产用途后与软件进行交互的最终用户。

  10. End users who interact with the software once it is released for production use.

每个软件项目都由属于这个分类的人组成。3为了提高效率,项目团队的组织方式必须能够最大限度地发挥每个人的技能和能力。这就是团队领导的工作。

Every software project is populated by people who fall within this taxonomy.3 To be effective, the project team must be organized in a way that maximizes each person’s skills and abilities. And that’s the job of the team leader.

24.2.2 团队领导

24.2.2 Team Leaders

项目管理是一项人员密集型活动,因此,有能力的从业者常常成为糟糕的团队领导者。他们根本不具备正确的人际交往能力。然而,正如 Edgemon 所说:“不幸的是,似乎经常发生的是,个人只是陷入了项目经理的角色,并意外地成为了项目经理”[Edg95]。共享领导通常有助于团队表现得更好,但团队领导者常常垄断决策权,无法为团队成员提供完成任务所需的自主权[Hoe16]。

Project management is a people-intensive activity, and for this reason, competent practitioners often make poor team leaders. They simply don’t have the right mix of people skills. And yet, as Edgemon states: “Unfortunately and all too frequently it seems, individuals just fall into a project manager role and become accidental project managers” [Edg95]. Shared leadership often helps teams perform better, but team leaders often monopolize decision-making authority and fail to provide team members with the levels of autonomy needed to complete their tasks [Hoe16].

James Kouzes 多年来一直在撰写有关各个技术领域有效领导力的文章。他列出了模范技术领导者的五种做法 [Kou14]:

James Kouzes has been writing about effective leadership in various technical areas for many years. He lists five practices found in exemplary technology leaders [Kou14]:

  • 树立榜样。领导者必须言出必行。他们通过共同牺牲表现出对团队和项目的承诺(例如,每天晚上最后一个回家或花时间成为软件应用程序的专家)。

  • Model the way. Leaders must practice what they preach. They demonstrate commitment to the team and project through shared sacrifice (e.g., by being the last one to go home each night or taking the time to become an expert on the software application).

  • 第494页激发灵感并共享愿景。领导者认识到,没有追随者,他们就无法领导。激励团队成员将个人愿望与团队目标联系起来非常重要。这意味着让利益相关者尽早参与目标设定过程。

  • Page 494Inspire and shared vision. Leaders recognize that they cannot lead without followers. It is important to motivate team members to tie their personal aspirations to the team goals. This means involving stakeholders early in the goal-setting process.

  • 挑战过程。领导者必须主动寻找创新方法来改进自己和团队的工作。鼓励团队成员尝试并承担风险,帮助他们经常取得小成功,同时从失败中吸取教训。

  • Challenge the process. Leaders must take the initiative to look for innovative ways to improve their own work and the work of their teams. Encourage team members to experiment and take risks by helping them generate frequent small successes while learning from their failures.

  • 使其他人能够采取行动。通过建立信任和促进关系来培养团队的协作能力。通过共享决策和目标设定来提高团队的能力感。

  • Enable others to act. Foster the team’s collaborative abilities by building trust and facilitating relationships. Increase the team’s sense of competence through sharing decision making and goal setting.

  • 勉励心。庆祝个人的成就。通过庆祝团队内外的共同目标和胜利来建立社区(团队)精神。

  • Encourage the heart. Celebrate the accomplishments of individuals. Build community (team) spirit by celebrating shared goals and victories, both inside and outside the team.

看待成功项目领导者的另一种方式可能是建议他们采用解决问题的管理风格。软件项目经理应该集中精力理解要解决的问题,协调利益相关者的想法流,并让团队中的每个人都知道(通过言语,更重要的是通过行动)质量始于每个人,他们的投入和贡献受到重视。

Another way of looking at successful project leaders might be to suggest that they adopt a problem-solving management style. A software project manager should concentrate on understanding the problem to be solved, coordinate the flow of ideas from stakeholders, and let everyone on the team know (by words and, far more important, by actions) that quality begins with each one of them and that their input and contributions are valued.

24.2.3 软件团队

24.2.3 The Software Team

用于软件开发的人员组织结构几乎与开发软件的组织一样多。无论好坏,组织结构都不能轻易改变。对组织变革的实际和政治后果的关注不属于软件项目经理的职责范围。然而,直接参与新软件项目的人员的组织属于项目经理的职权范围。

There are almost as many human organizational structures for software development as there are organizations that develop software. For better or worse, organizational structure cannot be easily modified. Concerns with the practical and political consequences of organizational change are not within the software project manager’s scope of responsibility. However, the organization of the people directly involved in a new software project is within the project manager’s purview.

“最佳”团队结构取决于组织的管理风格、团队人数及其技能水平以及整体问题的难度。Mantei [Man81] 描述了规划软件工程团队结构时应考虑的七个项目因素:(1)要解决的问题的难度,(2)生成的程序的“大小”(以代码行或代码行为单位)功能点,(3)团队在一起的时间(团队生命周期),(4)问题可以模块化的程度,(5)要构建的系统的质量和可靠性,(6)交付的刚性日期,以及 (7) 项目所需的社交(沟通)程度。

The “best” team structure depends on the management style of your organization, the number of people who will populate the team and their skill levels, and the overall problem difficulty. Mantei [Man81] describes seven project factors that should be considered when planning the structure of software engineering teams: (1) difficulty of the problem to be solved, (2) “size” of the resultant program(s) in lines of code or function points, (3) time that the team will stay together (team lifetime), (4) degree to which the problem can be modularized, (5) quality and reliability of the system to be built, (6) rigidity of the delivery date, and (7) degree of sociability (communication) required for the project.

无论团队组织如何,每个项目经理的目标都是帮助创建一个具有凝聚力的团队。DeMarco 和 Lister [DeM98]在他们的《Peopleware》一书中寻找“团结一致”的团队。他们写:

Regardless of team organization, the objective for every project manager is to help create a team that exhibits cohesiveness. In their book Peopleware, DeMarco and Lister [DeM98] look for teams that “jell.” They write:

凝聚团队是一群紧密团结在一起的人,整体大于各个部分的总和。。。

A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts . . .

一旦团队开始凝聚,成功的可能性就会大大增加。团队可以变得势不可挡,成为成功的主宰。。。他们不需要用传统的方式来管理,当然也不需要激励。他们有动力。

Once a team begins to jell, the probability of success goes way up. The team can become unstoppable, a juggernaut for success . . . They don’t need to be managed in the traditional way, and they certainly don’t need to be motivated. They’ve got momentum.

德马科和李斯特认为,凝胶团队的成员比平均水平显着提高生产力和积极性。他们有着共同的目标、共同的文化,而且在很多情况下,还有一种“精英意识”,这使他们独一无二。第495页

DeMarco and Lister contend that members of jelled teams are significantly more productive and more motivated than average. They share a common goal, a common culture, and in many cases, a “sense of eliteness” that makes them unique.Page 495

但并非所有球队都团结一致。事实上,许多团队都遭受着 Jackman [Jac98] 所说的“团队毒性”。她定义了“营造潜在有毒团队环境”的五个因素:(1)疯狂的工作氛围,(2)导致团队成员之间摩擦的高度挫败感,(3)“支离破碎或协调不善”的软件流程,(4)软件团队中的角色定义不明确,以及(5)“持续且反复地面临失败”。

But not all teams jell. In fact, many teams suffer from what Jackman [Jac98] calls “team toxicity.” She defines five factors that “foster a potentially toxic team environment”: (1) a frenzied work atmosphere, (2) high frustration that causes friction among team members, (3) a “fragmented or poorly coordinated” software process, (4) an unclear definition of roles on the software team, and (5) “continuous and repeated exposure to failure.”

为了避免疯狂的工作环境,项目经理应确保团队能够访问完成工作所需的所有信息,并且主要目的和目标一旦定义,除非绝对必要,否则不应修改。如果软件团队被赋予尽可能多的决策责任,就可以避免挫败感。通过了解要构建的产品和执行工作的人员并允许团队选择流程模型,可以避免不适当的流程(例如,不必要或繁重的工作任务或选择不当的工作产品)。团队本身应该建立自己的问责机制(技术审查4是实现这一目标的绝佳方法),并在团队成员未能执行任务时定义一系列纠正方法。最后,避免失败氛围的关键是建立基于团队的反馈和问题解决技术。

To avoid a frenzied work environment, the project manager should be certain that the team has access to all information required to do the job and that major goals and objectives, once defined, should not be modified unless absolutely necessary. A software team can avoid frustration if it is given as much responsibility for decision making as possible. An inappropriate process (e.g., unnecessary or burdensome work tasks or poorly chosen work products) can be avoided by understanding the product to be built and the people doing the work and by allowing the team to select the process model. The team itself should establish its own mechanisms for accountability (technical reviews4 are an excellent way to accomplish this) and define a series of corrective approaches when a member of the team fails to perform. And finally, the key to avoiding an atmosphere of failure is to establish team-based techniques for feedback and problem solving.

许多软件组织提倡敏捷软件开发(第 3 章),将其作为解决困扰软件项目工作的许多问题的解药。回顾一下,敏捷哲学鼓励客户满意度和软件的早期增量交付;小型、积极性高的项目团队;非正式方法;最小的软件工程工作产品;以及整体开发的简单性。

Many software organizations advocate agile software development (Chapter 3) as an antidote to many of the problems that have plagued software project work. To review, the agile philosophy encourages customer satisfaction and early incremental delivery of software; small, highly motivated project teams; informal methods; minimal software engineering work products; and overall development simplicity.

小而积极性高的项目团队,也称为敏捷团队,采用了上一节中讨论的成功软件项目团队的许多特征,并避免了许多产生问题的毒素[Hoe16]。然而,敏捷哲学强调个人(团队成员)的能力与团队协作作为团队成功的关键因素。Cockburn 和 Highsmith [Coc01a] 在写道时注意到这一点:

The small, highly motivated project team, also called an agile team, adopts many of the characteristics of successful software project teams discussed in the preceding section and avoids many of the toxins that create problems [Hoe16]. However, the agile philosophy stresses individual (team member) competency coupled with group collaboration as critical success factors for the team. Cockburn and Highsmith [Coc01a] note this when they write:

如果项目人员足够优秀,他们几乎可以使用任何流程并完成任务。如果他们不够好,任何流程都无法弥补他们的不足——“人胜过流程”是一种表达方式。然而,缺乏用户和高管的支持可能会扼杀一个项目——“政治胜过人”。即使是优秀的人,如果支持不足,也可能无法完成工作。。。

If the people on the project are good enough, they can use almost any process and accomplish their assignment. If they are not good enough, no process will repair their inadequacy—“people trump process” is one way to say this. However, lack of user and executive support can kill a project—“politics trump people.” Inadequate support can keep even good people from accomplishing the job . . .

为了有效利用每个团队成员的能力并通过软件项目促进有效的协作,敏捷团队是自组织的。

To make effective use of the competencies of each team member and to foster effective collaboration through a software project, agile teams are self-organizing.

许多敏捷过程模型(例如,Scrum)赋予敏捷团队很大的自主权来制定完成工作所需的项目管理和技术决策。规划保持在最低限度,并且团队可以选择自己的方法(例如流程、方法、工具),仅受业务需求和组织标准的约束。随着项目的进展,团队会自我组织,以在给定时间点对项目最有利的方式集中个人能力。

Many agile process models (e.g., Scrum) give the agile team significant autonomy to make the project management and technical decisions required to get the job done. Planning is kept to a minimum, and the team is allowed to select its own approach (e.g., process, methods, tools), constrained only by business requirements and organizational standards. As the project proceeds, the team self-organizes to focus individual competency in a way that is most beneficial to the project at a given point in time.

为了实现这一目标,敏捷团队可能会召开每日团队会议来协调和同步当天必须完成的工作。根据这些会议期间获得的信息,团队会调整其方法以完成增量工作。随着时间一天天过去,持续的自组织和协作使团队朝着完成软件增量的方向前进。第496页

To accomplish this, an agile team might conduct daily team meetings to coordinate and synchronize the work that must be accomplished for that day. Based on information obtained during these meetings, the team adapts its approach in a way that accomplishes an increment of work. As each day passes, continual self-organization and collaboration move the team toward a completed software increment.Page 496

24.2.4 协调和沟通问题

24.2.4 Coordination and Communication Issues

软件项目陷入困境的原因有很多。许多开发工作的规模很大,导致复杂性、混乱以及协调团队成员的重大困难。不确定性很常见,导致持续不断的变化,使项目团队陷入困境。互操作性已成为许多系统的关键特性。新软件必须与现有软件进行通信,并符合系统或产品预定义的约束。

There are many reasons that software projects get into trouble. The scale of many development efforts is large, leading to complexity, confusion, and significant difficulties in coordinating team members. Uncertainty is common, resulting in a continuing stream of changes that ratchets the project team. Interoperability has become a key characteristic of many systems. New software must communicate with existing software and conform to predefined constraints imposed by the system or product.

现代软件的这些特征——规模、不确定性和互操作性——是生活中的事实。为了有效地处理这些问题,您必须建立有效的方法来协调工作人员。为了实现这一目标,必须建立团队成员之间以及多个团队之间正式和非正式沟通的机制。正式沟通是通过“书面、结构化会议和其他相对非互动和非个人化的沟通渠道”来完成的[Kra95]。非正式的沟通更加个人化。软件团队的成员会临时分享想法,在出现问题时寻求帮助,并每天相互交流。

These characteristics of modern software—scale, uncertainty, and interoperability—are facts of life. To deal with them effectively, you must establish effective methods for coordinating the people who do the work. To accomplish this, mechanisms for formal and informal communication among team members and between multiple teams must be established. Formal communication is accomplished through “writing, structured meetings, and other relatively non-interactive and impersonal communication channels” [Kra95]. Informal communication is more personal. Members of a software team share ideas on an ad hoc basis, ask for help as problems arise, and interact with one another on a daily basis.

第497页

Page 497

24.3 产品

24.3 Product

软件项目经理在软件项目一开始就面临着两难的境地。需要定量估计和有组织的计划,但缺乏可靠的信息。对软件需求的详细分析将为估算提供必要的信息,但分析通常需要数周甚至数月才能完成。更糟糕的是,需求可能是不稳定的,随着项目的进展定期发生变化。然而,现在需要一个计划!

A software project manager is confronted with a dilemma at the very beginning of a software project. Quantitative estimates and an organized plan are required, but solid information is unavailable. A detailed analysis of software requirements would provide information necessary for estimates, but analysis often takes weeks or even months to complete. Worse, requirements may be fluid, changing regularly as the project proceeds. Yet, a plan is needed now!

不管你喜欢与否,你必须在项目一开始就检查产品及其要解决的问题。至少,必须确定产品的范围并对其进行限制。

Like it or not, you must examine the product and the problem it is intended to solve at the very beginning of the project. At a minimum, the scope of the product must be established and bounded.

24.3.1 软件范围

24.3.1 Software Scope

第一个软件项目管理活动是确定软件范围。范围是通过回答以下问题来定义的:

The first software project management activity is the determination of software scope. Scope is defined by answering the following questions:

  • 语境。要构建的软件如何适应更大的系统、产品或业务环境,以及由于环境而施加了哪些约束?

  • Context. How does the software to be built fit into a larger system, product, or business context, and what constraints are imposed as a result of the context?

  • 信息目标。软件的输出产生了哪些客户可见的数据对象?输入需要哪些数据对象?

  • Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input?

  • 功能和性能。该软件执行什么功能将输入数据转换为输出?是否有任何特殊的性能特征需要解决?

  • Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?

软件项目范围必须在管理和技术层面上明确且易于理解。软件范围的声明必须受到限制。也就是说,明确说明定量数据(例如,同时用户的数量、邮件列表的大小、最大允许响应时间),注明约束和/或限制(例如,产品成本限制内存大小),并指出缓解因素(例如,所需的算法很好理解并且可以在 Java 中使用)进行了描述。即使在最不稳定的情况下,也需要考虑原型的数量,并且需要设置第一个原型的范围。

Software project scope must be unambiguous and understandable at the management and technical levels. A statement of software scope must be bounded. That is, quantitative data (e.g., number of simultaneous users, size of mailing list, maximum allowable response time) are stated explicitly, constraints and/or limitations (e.g., product cost restricts memory size) are noted, and mitigating factors (e.g., desired algorithms are well understood and available in Java) are described. Even in the most fluid situations, the number of prototypes needs to be considered and the scope of the first prototype needs to be set.

24.3.2 问题分解

24.3.2 Problem Decomposition

问题分解,有时称为分区问题阐述,是软件需求分析的核心活动(第 7 章和8章)。在范围界定活动期间,不会尝试完全分解问题。相反,分解应用于两个主要领域:(1) 必须交付的功能和内容(信息);(2) 将用于交付它的过程。这可以使用功能列表或用例或敏捷工作、用户故事来完成。

Problem decomposition, sometimes called partitioning or problem elaboration, is an activity that sits at the core of software requirements analysis (Chapters 7 and 8). During the scoping activity, no attempt is made to fully decompose the problem. Rather, decomposition is applied in two major areas: (1) the functionality and content (information) that must be delivered and (2) the process that will be used to deliver it. This can be accomplished using a list of functions or with use cases or for agile work, user stories.

当人类面临复杂的问题时,倾向于采用分而治之的策略。简单地说,一个复杂的问题被划分为更易于管理的较小问题。这是项目规划开始时应用的策略。在开始评估之前(第25 章),对范围声明中描述的软件功能进行评估和完善,以提供更多详细信息。由于成本和进度估算都是以功能为导向的,因此某种程度的分解通常是有用的。类似地,主要内容或数据对象被分解为其组成部分,从而提供对软件生成的信息的合理理解。

Human beings tend to apply a divide-and-conquer strategy when they are confronted with a complex problem. Stated simply, a complex problem is partitioned into smaller problems that are more manageable. This is the strategy that applies as project planning begins. Software functions, described in the statement of scope, are evaluated and refined to provide more detail prior to the beginning of estimation (Chapter 25). Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful. Similarly, major content or data objects are decomposed into their constituent parts, providing a reasonable understanding of the information to be produced by the software.

第498页

Page 498

24.4 过程

24.4 Process

表征软件过程的框架活动(第 1 章)适用于所有软件项目。问题是选择适合项目团队设计的软件的流程模型。第 4 章中推荐的流程模型可能是许多项目团队考虑的良好起点。

The framework activities (Chapter 1) that characterize the software process are applicable to all software projects. The problem is to select the process model that is appropriate for the software to be engineered by your project team. The recommended process model in Chapter 4 may be a good starting point for many project teams to consider.

您的团队必须决定哪种流程模型最适合 (1) 请求产品的客户和将执行该工作的人员,(2) 产品本身的特征,以及 (3) 项目环境。软件团队工作。选择流程模型后,团队就会根据流程框架活动集定义初步项目计划。一旦初步计划确定,流程分解就开始了。也就是说,必须创建一个完整的计划,反映填充框架活动所需的工作任务。我们将在接下来的章节中简要探讨这些活动,并在第 25 章中提供更详细的视图。

Your team must decide which process model is most appropriate for (1) the customers who have requested the product and the people who will do the work, (2) the characteristics of the product itself, and (3) the project environment in which the software team works. When a process model has been selected, the team then defines a preliminary project plan based on the set of process framework activities. Once the preliminary plan is established, process decomposition begins. That is, a complete plan, reflecting the work tasks required to populate the framework activities, must be created. We explore these activities briefly in the sections that follow and present a more detailed view in Chapter 25.

24.4.1 融合产品和过程

24.4.1 Melding the Product and the Process

项目规划从产品和流程的融合开始。您的团队要设计的每个功能都必须通过为您的软件组织定义的一组框架活动。流程框架建立了项目规划的框架。它通过分配适合项目的任务集进行调整。假设组织已经采用了第 1 章中讨论的通用框架活动——沟通、规划、建模、构建和部署。

Project planning begins with the melding of the product and the process. Each function to be engineered by your team must pass through the set of framework activities that have been defined for your software organization. The process framework establishes a skeleton for project planning. It is adapted by allocating a task set that is appropriate to the project. Assume that the organization has adopted the generic framework activities—communication, planning, modeling, construction, and deployment—discussed in Chapter 1.

负责产品功能的团队成员将应用每个框架活动。本质上,创建了一个类似于图 24.1所示的矩阵。每个主要产品功能(图中列出了第 2 章中讨论的健身应用软件的功能)或用户故事都列在左侧栏中。框架活动列在顶行。软件工程工作任务(针对每个框架活动)将在下一行中输入。5项目经理(和其他团队成员)的工作是估计每个矩阵单元的资源需求、与每个单元相关的任务的开始和结束日期以及每个任务产生的工作产品。这些活动将在第 25 章中讨论。

The team members who work on a product function will apply each of the framework activities to it. In essence, a matrix similar to the one shown in Figure 24.1 is created. Each major product function (the figure lists functions for the fitness app software discussed in Chapter 2) or user story is listed in the left-hand column. Framework activities are listed in the top row. Software engineering work tasks (for each framework activity) would be entered in the following row.5 The job of the project manager (and other team members) is to estimate resource requirements for each matrix cell, start and end dates for the tasks associated with each cell, and work products to be produced as a consequence of each task. These activities are considered in Chapter 25.

24.1 融合问题和过程

Figure 24.1 Melding the problem and the process

24.4.2 流程分解

24.4.2 Process Decomposition

第499页软件团队在选择最适合项目的软件过程模型以及选择过程模型后填充过程模型的软件工程任务时应该具有很大程度的灵活性。与过去的工作类似的相对较小的项目可能最好使用单一冲刺方法来完成。如果期限如此紧迫,以至于无法合理地交付全部功能,那么增量策略可能是最好的。同样,具有其他特征(例如,不确定的需求、突破性技术、困难的客户或重要组件重用的潜力)的项目将导致选择其他过程模型。6

Page 499A software team should have a significant degree of flexibility in choosing the software process model that is best for the project and the software engineering tasks that populate the process model once it is chosen. A relatively small project that is similar to past efforts might be best accomplished using a single sprint approach. If the deadline is so tight that full functionality cannot reasonably be delivered, an incremental strategy might be best. Similarly, projects with other characteristics (e.g., uncertain requirements, breakthrough technology, difficult customers, or potential for significant component reuse) will lead to the selection of other process models.6

一旦选择了流程模型,流程框架就会适应它。在每种情况下,都可以使用前面讨论的通用流程框架。它适用于线性模型、迭代和增量模型、进化模型,甚至并发或组件组装模型。过程框架是不变的,并且是软件组织执行的所有工作的基础。

Once the process model has been chosen, the process framework is adapted to it. In every case, the generic process framework discussed earlier can be used. It will work for linear models, for iterative and incremental models, for evolutionary models, and even for concurrent or component assembly models. The process framework is invariant and serves as the basis for all work performed by a software organization.

但实际工作任务确实有所不同。当项目经理询问“我们如何完成这个框架活动?”时,流程分解就开始了。例如,一个相对简单的小型项目可能需要以下工作任务来进行通信活动:

But actual work tasks do vary. Process decomposition commences when the project manager asks, “How do we accomplish this framework activity?” For example, a small, relatively simple project might require the following work tasks for the communication activity:

  1. 制定一份澄清问题清单。

  2. Develop a list of clarification issues.

  3. 与利益相关者会面以解决澄清问题。

  4. Meet with stakeholders to address clarification issues.

  5. 通过列出用户故事共同制定范围声明。

  6. Jointly develop a statement of scope by listing the user stories.

  7. 与所有相关人员一起审查范围声明,并确定每个用户故事对利益相关者的重要性。

  8. Review the statement of scope with all concerned, and determine the importance of each user story to the stakeholders.

  9. 根据需要修改范围说明。

  10. Modify the statement of scope as required.

第 500 页这些事件可能在不到 48 小时的时间内发生。它们代表了适合小型、相对简单的项目的流程分解。

Page 500These events might occur over a period of less than 48 hours. They represent a process decomposition that is appropriate for the small, relatively simple project.

现在,考虑一个更复杂的项目,它具有更广泛的范围和更重大的业务影响。这样的项目可能需要以下工作任务来进行通信:

Now, consider a more complex project, which has a broader scope and more significant business impact. Such a project might require the following work tasks for the communication:

  1. 审查客户的要求。

  2. Review the customer request.

  3. 计划并安排与所有利益相关者举行一次正式的、便利的会议。

  4. Plan and schedule a formal, facilitated meeting with all stakeholders.

  5. 进行研究以指定拟议的解决方案和现有方法。

  6. Conduct research to specify the proposed solution and existing approaches.

  7. 准备正式会议的“工作文件”和议程。

  8. Prepare a “working document” and an agenda for the formal meeting.

  9. 主持会议。

  10. Conduct the meeting.

  11. 共同开发反映软件数据、功能和行为特征的迷你规格。这通常是通过开发从用户的角度描述软件的用例来完成的。

  12. Jointly develop mini-specs that reflect data, function, and behavioral features of the software. This is often done by developing use cases that describe the software from the user’s point of view.

  13. 检查每个迷你规范或用例的正确性、一致性和不含糊之处。

  14. Review each mini-spec or use case for correctness, consistency, and lack of ambiguity.

  15. 将小型规范汇总到范围界定文档中。

  16. Assemble the mini-specs into a scoping document.

  17. 与所有相关人员一起审查用例的收集,并确定它们对所有利益相关者的相对重要性。

  18. Review the collection of use cases with all concerned, and determine their relative importance to all stakeholders.

  19. 根据需要修改范围界定文档或用例。

  20. Modify the scoping document or use cases as required.

这两个项目都执行我们称之为通信的框架活动但第一个项目团队执行的软件工程工作任务是第二个项目团队的一半。

Both projects perform the framework activity that we call communication, but the first project team performs half as many software engineering work tasks as the second.

24.5 项目

24.5 Project

要管理成功的软件项目,您必须了解可能出现问题的地方,以便避免问题。在一篇关于软件项目的优秀论文中,John Reel [Ree99] 定义了表明信息系统项目处于危险之中的迹象。在某些情况下,软件人员不了解客户的需求。这导致项目范围定义不明确。在其他项目中,变更管理不善。有时,所选技术发生变化或业务需求发生变化,管理层就会失去支持。管理层可能会设定不切实际的最后期限,或者最终用户可能会抵制新系统。在某些情况下,项目团队根本不具备必要的技能。最后,有些开发人员似乎永远不会从错误中吸取教训。

To manage a successful software project, you have to understand what can go wrong so that problems can be avoided. In an excellent paper on software projects, John Reel [Ree99] defines signs that indicate that an information systems project is in jeopardy. In some cases, software people don’t understand their customer’s needs. This leads to a project with a poorly defined scope. In other projects, changes are managed poorly. Sometimes the chosen technology changes or business needs shift and management sponsorship is lost. Management can set unrealistic deadlines or end users can be resistant to the new system. There are cases in which the project team simply does not have the requisite skills. And finally, there are developers who never seem to learn from their mistakes.

疲惫不堪的行业专业人士在讨论特​​别困难的软件项目时经常提到“90-90 规则”:系统的前 90% 占用了 90% 的分配工作量和时间。最后 10% 需要另外 90% 的分配精力和时间 [Zah94]。导致 90-90 规则的种子包含在上一段中提到的符号中。

Jaded industry professionals often refer to the “90–90 rule” when discussing particularly difficult software projects: The first 90 percent of a system absorbs 90 percent of the allotted effort and time. The last 10 percent takes another 90 percent of the allotted effort and time [Zah94]. The seeds that lead to the 90–90 rule are contained in the signs noted in the preceding paragraph.

但消极情绪已经够多了!成功的软件项目有哪些特征?Ghazi [Gha14] 和她的同事注意到成功的软件项目中存在的几个特征,并且在大多数精心设计的流程模型中也发现了这些特征。第501页

But enough negativity! What are the characteristics of successful software projects? Ghazi [Gha14] and her colleagues note several characteristics that are present in successful software projects and also found in most well-designed process models.Page 501

  1. 所有利益相关者都接受清晰且易于理解的要求

  2. Clear and well-understood requirements accepted by all stakeholders

  3. 用户在整个开发过程中积极、持续的参与

  4. Active and continuous participation of users throughout the development process

  5. 具有所需领导技能的项目经理,能够与团队分享项目愿景

  6. A project manager with required leadership skills who is able to share project vision with the team

  7. 在利益相关者参与下制定的项目计划和时间表,以实现用户目标

  8. A project plan and schedule developed with stakeholder participation to achieve user goals

  9. 熟练且敬业的团队成员

  10. Skilled and engaged team members

  11. 性格兼容并喜欢在协作环境中工作的开发团队成员

  12. Development team members with compatible personalities who enjoy working in a collaborative environment

  13. 受监控和维护的切合实际的时间表和预算估算

  14. Realistic schedule and budget estimates which are monitored and maintained

  15. 客户需求得到理解和满足

  16. Customer needs that are understood and satisfied

  17. 具有高度工作满意度的团队成员

  18. Team members who experience a high degree of job satisfaction

  19. 反映所需范围和质量的工作产品

  20. A working product that reflects desired scope and quality

24.6 W 5 HH原则

24.6 The W5HH Principle

在一篇关于软件流程和项目的优秀论文中,Barry Boehm [Boe96] 指出:“您需要一种组织原则,可以缩小规模,为简单的项目提供简单的[项目]计划。” Boehm 提出了一种解决项目目标、里程碑和时间表、职责、管理和技术方法以及所需资源的方法。在提出一系列问题后,他将其称为W 5 HH 原则,从而定义了关键项目特征和最终的项目计划:

In an excellent paper on software process and projects, Barry Boehm [Boe96] states: “[Y]ou need an organizing principle that scales down to provide simple [project] plans for simple projects.” Boehm suggests an approach that addresses project objectives, milestones and schedules, responsibilities, management and technical approaches, and required resources. He calls it the W5HH Principle, after a series of questions that lead to a definition of key project characteristics and the resultant project plan:

  • 为什么要开发这个系统?所有利益相关者都应该评估软件工作的商业原因的有效性。商业目的是否证明投入人力、时间和金钱是合理的?

  • Why is the system being developed? All stakeholders should assess the validity of business reasons for the software work. Does the business purpose justify the expenditure of people, time, and money?

  • 将会做什么?定义了项目所需的任务集。

  • What will be done? The task set required for the project is defined.

  • 什么时候能完成?团队通过确定何时执行项目任务以及何时达到里程碑来建立项目进度表。

  • When will it be done? The team establishes a project schedule by identifying when project tasks are to be conducted and when milestones are to be reached.

  • 谁负责某项职能?定义了软件团队每个成员的角色和责任。

  • Who is responsible for a function? The role and responsibility of each member of the software team is defined.

  • 他们在组织上位于哪里?并非所有角色和职责都由软件从业人员承担。客户、用户和其他利益相关者也有责任。

  • Where are they located organizationally? Not all roles and responsibilities reside within software practitioners. The customer, users, and other stakeholders also have responsibilities.

  • 这项工作在技术和管理上将如何完成?一旦产品范围确定,就必须定义项目的管理和技术策略。

  • How will the job be done technically and managerially? Once product scope is established, a management and technical strategy for the project must be defined.

  • 每种资源需要多少?这个问题的答案是根据之前问题的答案进行估计(第 25 章)得出的。

  • How much of each resource is needed? The answer to this question is derived by developing estimates (Chapter 25) based on answers to earlier questions.

无论软件项目的规模或复杂程度如何,Boehm 的 W 5 HH 原则都适用。所提出的问题为您和您的团队提供了出色的规划大纲。

Boehm’s W5HH principle is applicable regardless of the size or complexity of a software project. The questions noted provide you and your team with an excellent planning outline.

第502页

Page 502

24.7 关键实践

24.7 Critical Practices

艾尔利委员会7制定了一份“基于绩效的管理的关键软件实践”清单。这些实践“一直被高度成功的软件项目和组织所使用,并被认为至关重要,这些项目和组织的‘底线’性能始终远高于行业平均水平”[Air99]。这些实践仍然适用于所有软件项目的现代基于绩效的管理[All14]。

The Airlie Council7 has developed a list of “critical software practices for performance-based management.” These practices are “consistently used by, and considered critical by, highly successful software projects and organizations whose ‘bottom line’ performance is consistently much better than industry averages” [Air99]. These practices are still applicable to modern performance-based management of all software projects [All14].

关键实践8包括:基于度量的项目管理(第23章)、经验成本和进度估计(第25章)、挣值跟踪(第25章)、针对质量目标的缺陷跟踪(第19章第24章)。这些关键实践中的每一个都在本书的第四部分中得到了讨论。

Critical practices8 include: metric-based project management (Chapter 23), empirical cost and schedule estimation (Chapter 25), earned value tracking (Chapter 25), defect tracking against quality targets (Chapters 19 through Chapter 24). Each of these critical practices is addressed throughout Part Four of this book.

24.8 总结

24.8 Summary

软件项目管理是软件工程中的一项总括活动。它在任何技术活动启动之前就开始,并持续贯穿计算机软件的建模、构建和部署。

Software project management is an umbrella activity within software engineering. It begins before any technical activity is initiated and continues throughout the modeling, construction, and deployment of computer software.

四个 P 对软件项目管理具有重大影响:人员、产品、流程和项目。必须将人们组织成有效的团队,激励他们完成高质量的软件工作,并进行协调以实现有效的沟通。产品需求必须从客户传达给开发人员,划分(分解)为其组成部分,并由软件团队定位以供工作。该流程必须适应人员和问题。选择一个通用的流程框架,应用适当的软件工程范例,并选择一组工作任务来完成工作。最后,项目的组织方式必须能够使软件团队取得成功。

Four Ps have a substantial influence on software project management—people, product, process, and project. People must be organized into effective teams, motivated to do high-quality software work, and coordinated to achieve effective communication. Product requirements must be communicated from customer to developer, partitioned (decomposed) into their constituent parts, and positioned for work by the software team. The process must be adapted to the people and the problem. A common process framework is selected, an appropriate software engineering paradigm is applied, and a set of work tasks is chosen to get the job done. Finally, the project must be organized in a manner that enables the software team to succeed.

所有软件项目的关键要素是人。软件工程师可以组织成多种不同的团队结构,从传统的控制层次结构到“开放范式”团队。可以应用各种协调和沟通技术来支持团队的工作。一般来说,技术评审和非正式的人与人之间的交流对于从业者来说最有价值。

The pivotal element in all software projects is people. Software engineers can be organized in a number of different team structures that range from traditional control hierarchies to “open paradigm” teams. A variety of coordination and communication techniques can be applied to support the work of the team. In general, technical reviews and informal person-to-person communication have the most value for practitioners.

项目管理活动包括测量和指标、估计和调度、风险分析、跟踪和控制。接下来的章节将讨论每个主题。

The project management activity encompasses measurement and metrics, estimation and scheduling, risk analysis, tracking, and control. Each of these topics is considered in the chapters that follow.

第503页

Page 503

问题与思考点

Problems and Points to Ponder

24.1。根据本章中包含的信息和您自己的经验,制定“10 条戒律”来增强软件工程师的能力。也就是说,列出 10 条指南,这些指南将引导软件人员充分发挥潜力。

24.1. Based on information contained in this chapter and your own experience, develop “10 commandments” for empowering software engineers. That is, make a list of 10 guidelines that will lead to software people who work to their full potential.

24.2. 软件工程学院的人员能力成熟度模型(People-CMM)对培养优秀软件人才的“关键实践领域”(KPA)进行了有组织的审视。您的导师将为您分配一个 KPA 进行分析和总结。

24.2. The Software Engineering Institute’s People Capability Maturity Model (People-CMM) takes an organized look at “key practice areas” (KPAs) that cultivate good software people. Your instructor will assign you one KPA for analysis and summary.

24.3。描述客户和最终用户相同的三种现实生活情况。描述三种不同的情况。

24.3. Describe three real-life situations in which the customer and the end user are the same. Describe three situations in which they are different.

24.4。高级管理层做出的决策会对软件工程团队的效率产生重大影响。举五个例子来说明这是真的。

24.4. The decisions made by senior management can have a significant impact on the effectiveness of a software engineering team. Provide five examples to illustrate that this is true.

24.5。您被任命为信息系统组织内的项目经理。您的工作是构建一个与您的团队构建的其他应用程序非常相似的应用程序,尽管这个应用程序更大、更复杂。客户已将要求彻底记录在案。您会选择什么样的团队结构以及为什么?您会选择什么软件过程模型以及为什么?

24.5. You have been appointed a project manager within an information systems organization. Your job is to build an application that is quite similar to others your team has built, although this one is larger and more complex. Requirements have been thoroughly documented by the customer. What team structure would you choose and why? What software process model(s) would you choose and why?

24.6。您被任命为一家小型软件产品公司的项目经理。您的工作是构建一款突破性的产品,将虚拟现实硬件与最先进的软件相结合。由于家庭娱乐市场的竞争非常激烈,完成工作面临着巨大的压力。您会选择什么样的团队结构以及为什么?您会选择什么软件过程模型以及为什么?

24.6. You have been appointed a project manager for a small software products company. Your job is to build a breakthrough product that combines virtual reality hardware with state-of-the-art software. Because competition for the home entertainment market is intense, there is significant pressure to get the job done. What team structure would you choose and why? What software process model(s) would you choose and why?

24.7。您被任命为一家大型软件产品公司的项目经理。您的工作是管理其广泛使用的移动健身应用程序的下一代版本的开发。由于竞争激烈,因此确定并宣布了紧迫的期限。您会选择什么样的团队结构以及为什么?您会选择什么软件过程模型以及为什么?

24.7. You have been appointed a project manager for a major software products company. Your job is to manage the development of the next-generation version of its widely used mobile fitness app. Because competition is intense, tight deadlines have been established and announced. What team structure would you choose and why? What software process model(s) would you choose and why?

24.8。您被任命为一家为基因工程领域提供服务的公司的软件项目经理。您的工作是管理新软件产品的开发,该产品将加快基因分型的步伐。这项工作以研发为导向,但目标是在明年生产出产品。您会选择什么样的团队结构以及为什么?您会选择什么软件过程模型以及为什么?

24.8. You have been appointed a software project manager for a company that services the genetic engineering world. Your job is to manage the development of a new software product that will accelerate the pace of gene typing. The work is R&D oriented, but the goal is to produce a product within the next year. What team structure would you choose and why? What software process model(s) would you choose and why?

24.9。您被要求开发一个小型应用程序,用于分析大学提供的每门课程并报告该课程(给定学期)获得的平均成绩。写一个范围声明来限制这个问题。

24.9. You have been asked to develop a small application that analyzes each course offered by a university and reports the average grade obtained in the course (for a given term). Write a statement of scope that bounds this problem.

24.10。您认为软件项目人员管理最重要的方面是什么?

24.10. What, in your opinion, is the most important aspect of people management for a software project?

1尝试在 Dilbert 网站上搜索术语“管理” :http://dilbert.com/。

1 Try searching for the term management on the Dilbert website: http://dilbert.com/.

2鉴于这些统计数据,我们有理由问计算机的影响如何继续呈指数级增长。我们认为,部分答案是,这些“失败”的项目中有相当一部分从一开始就考虑不周。客户很快就会失去兴趣(因为他们所要求的并不像他们最初想象的那么重要),并且项目被取消。

2 Given these statistics, it’s reasonable to ask how the impact of computers continues to grow exponentially. Part of the answer, we think, is that a substantial number of these “failed” projects are ill conceived in the first place. Customers lose interest quickly (because what they’ve requested wasn’t really as important as they first thought), and the projects are cancelled.

3开发 Web 应用程序、移动应用程序或游戏时,其他非技术人员可能会参与内容创建。

3 When WebApps, MobileApps, or games are developed, other nontechnical people may be involved in content creation.

4第 16 章详细讨论了技术审查。

4 Technical reviews are discussed in detail in Chapter 16.

5应当指出的是,工作任务必须根据一些适应标准适应项目的具体需求。

5 It should be noted that work tasks must be adapted to the specific needs of the project based on a number of adaptation criteria.

6回想一下,项目特征也对软件团队的结构有很大影响(第 24.2.3 节)。

6 Recall that project characteristics also have a strong bearing on the structure of the software team (Section 24.2.3).

7艾尔利委员会由美国国防部特许的软件工程专家团队组成,旨在帮助制定软件项目管理和软件工程最佳实践指南。

7 The Airlie Council was comprised of a team of software engineering experts chartered by the U.S. Department of Defense to help develop guidelines for best practices in software project management and software engineering.

8此处仅提及与“项目完整性”相关的关键实践。

8 Only those critical practices associated with “project integrity” are noted here.

第504页

Page 504

章节

chapter

25创建可行的软件计划

25 Creating a Viable Software Plan

软件项目管理始于一组统称为项目规划的活动。在项目开始之前,软件团队会估计要完成的工作、所需的资源以及从开始到完成所需的时间。一旦这些活动完成,软件团队应该建立一个项目进度表,定义软件工程任务和里程碑,确定谁负责执行每项任务,并指定可能对进度有很大影响的任务间依赖关系。

Software project management begins with a set of activities that are collectively called project planning. Before the project can begin, the software team estimates the work to be done, the resources that will be required, and the time that will elapse from start to finish. Once these activities are accomplished, the software team should establish a project schedule that defines software engineering tasks and milestones, identifies who is responsible for conducting each task, and specifies the intertask dependencies that may have a strong bearing on progress.

第505页曾经有一位目光明亮的年轻工程师被选中为自动化制造应用程序开发一些代码。选择他的原因很简单。他是团队中唯一了解制造控制器来龙去脉的人,但当时他对软件工程一无所知,更不知道项目调度和跟踪。

Page 505There was once a bright-eyed young engineer who was chosen to develop some code for an automated manufacturing application. The reason for his selection was simple. He was the only person in his group who knew the ins and outs of the manufacturing controller, but at the time he knew nothing about software engineering and even less about project scheduling and tracking.

他的老板告诉这位年轻的工程师,这个项目必须在两个月内完成。他考虑了自己的方法并开始编写代码。两周后,老板把他叫到办公室,询问事情进展如何。

His boss informed the young engineer that the project had to be completed in 2 months. He considered his approach and began writing code. After 2 weeks, the boss called him into his office and asked how things were going.

“真是太棒了。”年轻的工程师满怀青春的热情说道。“这比我想象的要简单得多。我可能已经完成了接近 75%。”

“Really great,” said the young engineer with youthful enthusiasm. “This is much simpler than I thought. I’m probably close to 75 percent finished.”

老板微笑着鼓励年轻的工程师再接再厉。他们计划一周后再次见面。

The boss smiled and encouraged the young engineer to keep up the good work. They planned to meet again in a week’s time.

一周后,老板把工程师叫到他的办公室,问:“我们在哪里?”

A week later the boss called the engineer into his office and asked, “Where are we?”

“一切都很顺利,”年轻人说,“但我遇到了一些小障碍。我会解决这些问题并尽快回到正轨。”

“Everything’s going well,” said the youngster, “but I’ve run into a few small snags. I’ll get them ironed out and be back on track soon.”

“截止日期看起来怎么样?” 老板问道。

“How does the deadline look?” the boss asked.

“没问题,”工程师说。“我已经完成了接近 90%。”

“No problem,” said the engineer. “I’m close to 90 percent complete.”

如果您已经在软件世界工作了几年以上,那么您就可以完成这个故事。毫不奇怪,年轻的工程师1在整个项目期间都完成了 90%,并且(在其他人的帮助下)仅晚了 1 个月就完成了。

If you’ve been working in the software world for more than a few years, you can finish the story. It’ll come as no surprise that the young engineer1 stayed 90 percent complete for the entire project duration and finished (with the help of others) only 1 month late.

在过去的五年里,这个故事已经被软件开发人员重复了数十万次。最大的问题是为什么。

This story has been repeated hundreds of thousands of times by software developers during the past five decades. The big question is why.

25.1 对估计的评论

25.1 Comments on Estimation

规划要求您做出初步承诺,即使这个“承诺”很可能会被证明是错误的。每当做出估计时,您都必须展望未来并理所当然地接受一定程度的不确定性。

Planning requires you to make an initial commitment, even though it’s likely that this “commitment” will be proven wrong. Whenever estimates are made, you have to look into the future and accept some degree of uncertainty as a matter of course.

估算既是一门艺术,也是一门科学,不应该以随意的方式进行。因为估算为所有其他项目规划行动奠定了基础,而项目规划为成功的软件工程提供了路线图,所以如果没有它,我们就不建议开始。

Estimating is as much art as it is science, and it should not be conducted in a haphazard manner. Because estimation lays a foundation for all other project planning actions, and project planning provides the road map for successful software engineering, we would be ill-advised to embark without it.

对软件开发的资源、成本和进度的估计需要经验、获得良好的历史信息(例如过程和产品指标),以及在仅存在定性信息时进行定量预测的勇气。估计存在固有风险2 ,并且这种风险会导致不确定性。项目复杂性、项目规模和结构不确定性程度都会影响估算的可靠性。

Estimation of resources, cost, and schedule for software development requires experience, access to good historical information (e.g., process and product metrics), and the courage to commit to quantitative predictions when qualitative information is all that exists. Estimation carries inherent risk,2 and this risk leads to uncertainty. Project complexity, project size, and the degree of structural uncertainty all affect the reliability of estimates.

项目复杂性对规划中固有的不确定性有很大影响。然而,复杂性是一个相对衡量标准,受到对过去工作的熟悉程度的影响。复杂的电子商务应用程序的首次开发人员可能会认为它极其复杂。然而,开发第十个电子商务 Web 应用程序的 Web 工程团队会考虑这种常规工作。已经提出了许多定量的软件复杂性度量[Zus97],但它们很少在实际项目中使用。然而,其他更主观的复杂性评估(例如,第 25.6 节中描述的功能点复杂性调整因素)可以在规划过程的早期建立。第506页

Project complexity has a strong effect on the uncertainty inherent in planning. Complexity, however, is a relative measure that is affected by familiarity with past efforts. The first-time developer of a sophisticated e-commerce application might consider it to be exceedingly complex. However, a Web engineering team developing its tenth e-commerce WebApp would consider such work run of the mill. A number of quantitative software complexity measures have been proposed [Zus97], but they are rarely used in real-world projects. However, other, more subjective assessments of complexity (e.g., function point complexity adjustment factors described in Section 25.6) can be established early in the planning process.Page 506

项目规模是影响估算准确性和有效性的另一个重要因素。随着规模的增加,软件各个元素之间的相互依赖性迅速增长。3问题分解是一种重要的估算方法,但它变得更加困难,因为问题要素的细化可能仍然很困难。套用墨菲定律:“可能出错的事情就一定会出错”——如果有更多的事情可能失败,就会有更多的事情失败。

Project size is another important factor that can affect the accuracy and efficacy of estimates. As size increases, the interdependency among various elements of the software grows rapidly.3 Problem decomposition, an important approach to estimating, becomes more difficult because the refinement of problem elements may still be formidable. To paraphrase Murphy’s law: “What can go wrong will go wrong”—and if there are more things that can fail, more things will fail.

结构不确定性的程度也对估计风险有影响。在这种情况下,结构是指需求的固化程度、功能划分的难易程度以及必须处理的信息的层次性质。

The degree of structural uncertainty also has an effect on estimation risk. In this context, structure refers to the degree to which requirements have been solidified, the ease with which functions can be compartmentalized, and the hierarchical nature of the information that must be processed.

历史信息的可用性对估计风险有很大影响。通过回顾,您可以效仿有效的做法并改进出现问题的领域。当对过去的项目有全面的软件指标(第23章)时,可以更有把握地进行估计,可以制定时间表以避免过去的困难,并降低总体风险。

The availability of historical information has a strong influence on estimation risk. By looking back, you can emulate things that worked and improve areas where problems arose. When comprehensive software metrics (Chapter 23) are available for past projects, estimates can be made with greater assurance, schedules can be established to avoid past difficulties, and overall risk is reduced.

如果对项目范围了解甚少或项目要求可能发生变化,不确定性和估计风险就会变得非常高。作为规划者,您和客户应该认识到软件需求的可变性意味着成本和进度的不稳定。

If project scope is poorly understood or project requirements are subject to change, uncertainty and estimation risk become dangerously high. As a planner, you and the customer should recognize that variability in software requirements means instability in cost and schedule.

但是,您不应该过分沉迷于估算。现代软件工程方法(例如,演化过程模型)采用迭代的开发观点。在这种方法中,可以重新审视估计(因为已知更多信息)并在利益相关者对需求或时间表进行更改时对其进行修改。

However, you should not become obsessive about estimation. Modern software engineering approaches (e.g., evolutionary process models) take an iterative view of development. In such approaches, it is possible to revisit estimates (as more information is known) and revise them when stakeholders make changes to requirements or schedules.

25.2 项目规划过程

25.2 The Project Planning Process

软件项目规划的目标是提供一个框架,使经理能够对资源、成本和进度做出合理的估计。此外,估算应尝试定义最佳情况和最坏情况,以便限制项目结果。尽管存在一定程度的不确定性,但软件团队仍着手制定根据项目规划任务集而制定的计划。因此,该计划必须随着项目的进展进行调整和更新。在以下各节中,将讨论与软件项目规划任务集相关的每项活动。第507页

The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. In addition, estimates should attempt to define best-case and worst-case scenarios so that project outcomes can be bounded. Although there is an inherent degree of uncertainty, the software team embarks on a plan that has been established as a consequence of a project planning task set. Therefore, the plan must be adapted and updated as the project proceeds. In the following sections, each of the activities associated with the software project planning task set is discussed.Page 507

25.3 软件范围和可行性

25.3 Software Scope and Feasibility

软件范围描述了要交付给最终用户的功能和特性;输入和输出的数据;由于使用该软件而呈现给用户的“内容”;以及约束系统的性能、约束、接口和可靠性。范围可以通过开发一组与最终用户一起开发的用例4来定义。

Software scope describes the functions and features that are to be delivered to end users; the data that are input and output; the “content” that is presented to users as a consequence of using the software; and the performance, constraints, interfaces, and reliability that bound the system. Scope can be defined by developing a set of use cases4 that is developed with the end users.

对用例中描述的功能进行评估,并在某些情况下进行细化,以在开始估计之前提供更多详细信息。由于成本和进度估算都是以功能为导向的,因此某种程度的分解通常是有用的。性能考虑通常会限制处理和响应时间要求。

Functions described in the use cases are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful. Performance considerations often constrain processing and response-time requirements.

一旦确定了范围(经客户同意),就有理由问:“我们可以构建软件来满足这个范围吗?这个项目可行吗?” 很多时候,软件工程师匆忙地忽略了这些问题(或者被不耐烦的经理或其他利益相关者推过),结果却陷入了一个从一开始就注定要失败的项目中。您必须尝试确定是否可以使用可用的技术、资金、时间和其他资源来创建该系统。项目可行性很重要,但考虑业务需求更为重要。建立一个没人想要的高科技系统或产品是没有任何好处的。

Once scope has been identified (with the concurrence of the customer), it is reasonable to ask: “Can we build software to meet this scope? Is the project feasible?” All too often, software engineers rush past these questions (or are pushed past them by impatient managers or other stakeholders), only to become mired in a project that is doomed from the onset. You must try to determine if the system can be created using available technology, dollars, time, and other resources. Project feasibility is important, but a consideration of business need is even more important. It does no good to build a high-tech system or product that no one wants.

25.4 资源

25.4 Resources

定义范围后,您必须估计构建将实现描述软件特性和功能的用例集的软件所需的资源。图 25.1描述了软件工程资源的三大类——人员、可重用软件组件和开发环境(硬件和软件工具)。每个资源都指定有四个特征:资源描述、可用性声明、需要资源的时间以及应用资源的持续时间。最后两个特征可以被视为一个时间窗口。必须在最早的实际时间确定指定窗口的资源可用性。第508页

Once scope is defined, you must estimate the resources required to build software that will implement the set of use cases that describe software features and functions. Figure 25.1 depicts the three major categories of software engineering resources—people, reusable software components, and the development environment (hardware and software tools). Each resource is specified with four characteristics: description of the resource, a statement of availability, time when the resource will be required, and duration of time that the resource will be applied. The last two characteristics can be viewed as a time window. Availability of the resource for a specified window must be established at the earliest practical time.Page 508

图25.1项目 资源

Figure 25.1 Project resources

25.4.1 人力资源

25.4.1 Human Resources

规划者首先评估软件范围并选择完成开发所需的技能。组织职位(如经理、高级软件工程师)和专业(如电信、数据库、电子商务)均被指定。对于相对较小的项目(几个人月),一个人可以执行所有软件工程任务,并根据需要咨询专家。对于较大的项目,软件团队可能在地理上分散在许多不同的地点。因此,每个人力资源的位置都被指定。

The planner begins by evaluating software scope and selecting the skills required to complete development. Both organizational position (e.g., manager, senior software engineer) and specialty (e.g., telecommunications, database, e-commerce) are specified. For relatively small projects (a few person-months), a single individual may perform all software engineering tasks, consulting with specialists as required. For larger projects, the software team may be geographically dispersed across a number of different locations. Hence, the location of each human resource is specified.

只有在估计开发工作量(例如,人月)之后才能确定软件项目所需的人员数量。本章稍后将讨论估计工作量的技术。第509页

The number of people required for a software project can be determined only after an estimate of development effort (e.g., person-months) is made. Techniques for estimating effort are discussed later in this chapter.Page 509

25.4.2 可重用软件资源

25.4.2 Reusable Software Resources

基于组件的软件工程(CBSE) 5强调可重用性,即软件构建块的创建和重用。这些构建块(通常称为组件)必须进行编目以便于参考,进行标准化以便于应用,并进行验证以便于集成。

Component-based software engineering (CBSE)5 emphasizes reusability—that is, the creation and reuse of software building blocks. Such building blocks, often called components, must be cataloged for easy reference, standardized for easy application, and validated for easy integration.

讽刺的是,可重用的软件组件在规划过程中经常被忽视,而在软件过程的开发阶段却成为最重要的问题。最好尽早指定软件资源需求。通过这种方式,可以对替代方案进行技术评估并及时进行采购。同样重要的是要考虑购买现有软件产品(假设它满足所有利益相关者的需求)是否比从头开始构建定制软件产品的成本更低。

Ironically, reusable software components are often neglected during planning, only to become a paramount concern during the development phase of the software process. It is better to specify software resource requirements early. In this way technical evaluation of the alternatives can be conducted and timely acquisition can occur. It is also important to consider whether it would be less costly to buy an existing software product (assuming it satisfies all stakeholder needs) than building a custom software product from scratch.

25.4.3 环境资源

25.4.3 Environmental Resources

支持软件项目的环境通常称为软件工程环境(SEE),包含硬件和软件。硬件提供了一个平台,支持生成工作产品所需的工具(软件),这些工作产品是良好软件工程实践的结果。6由于大多数软件组织都有多个需要访问 SEE 的选区,因此您必须规定硬件和软件所需的时间窗口,并验证这些资源是否可用。

The environment that supports a software project, often called the software engineering environment (SEE), incorporates hardware and software. Hardware provides a platform that supports the tools (software) required to produce the work products that are an outcome of good software engineering practice.6 Because most software organizations have multiple constituencies that require access to the SEE, you must prescribe the time window required for hardware and software and verify that these resources will be available.

当要设计基于计算机的系统(包含专用硬件和软件)时,软件团队可能需要访问其他工程团队正在开发的硬件元素。例如,制造单元内使用的机器人设备的软件可能需要特定的机器人(例如机器人焊工)作为验证测试​​步骤的一部分;用于高级页面布局的软件项目在开发过程中的某个时刻可能需要高速数字打印系统。每个硬件元素都必须作为规划的一部分进行指定。

When a computer-based system (incorporating specialized hardware and software) is to be engineered, the software team may require access to hardware elements being developed by other engineering teams. For example, software for a robotic device used within a manufacturing cell may require a specific robot (e.g., a robotic welder) as part of the validation test step; a software project for advanced page layout may need a high-speed digital printing system at some point during development. Each hardware element must be specified as part of planning.

25.5 数据分析和软件项目估算

25.5 Data Analytics and Software Project Estimation

软件成本和工作量估算永远不会是一门精确的科学。太多的变量——人力、技术、环境、政治——会影响软件的最终成本和开发它的努力。然而,软件项目估算可以从黑魔法转变为一系列系统步骤,提供具有可接受风险的估算。为了实现可靠的成本和工作量估算,出现了多种选择:

Software cost and effort estimation will never be an exact science. Too many variables—human, technical, environmental, political—can affect the ultimate cost of software and effort applied to develop it. However, software project estimation can be transformed from a black art to a series of systematic steps that provide estimates with acceptable risk. To achieve reliable cost and effort estimates, a number of options arise:

  1. 将估算推迟到项目后期(显然,在项目完成后我们可以实现 100% 准确的估算!)。

  2. Delay estimation until late in the project (obviously, we can achieve 100 percent accurate estimates after the project is complete!).

  3. 第510页根据已完成的类似项目进行估算。

  4. Page 510Base estimates on similar projects that have already been completed.

  5. 使用相对简单的分解技术来生成项目成本和工作量估算。

  6. Use relatively simple decomposition techniques to generate project cost and effort estimates.

  7. 使用一个或多个经验模型来估计软件成本和工作量。

  8. Use one or more empirical models for software cost and effort estimation.

不幸的是,第一个选择无论多么有吸引力,但并不实用。必须预先提供成本估算。然而,你应该认识到,你等待的时间越长,你知道的就越多,而你知道的越多,你在估计中犯严重错误的可能性就越小。

Unfortunately, the first option, however attractive, is not practical. Cost estimates must be provided up front. However, you should recognize that the longer you wait, the more you know, and the more you know, the less likely you are to make serious errors in your estimates.

如果当前项目与过去的工作非常相似并且其他项目影响(例如,客户、业务条件、软件工程环境、截止日期)大致相当,则第二种选择可以相当好地工作。不幸的是,过去的经验并不总是未来结果的良好指标。

The second option can work reasonably well, if the current project is quite similar to past efforts and other project influences (e.g., the customer, business conditions, the software engineering environment, deadlines) are roughly equivalent. Unfortunately, past experience has not always been a good indicator of future results.

其余选项是软件项目评估的可行方法。理想情况下,每个选项所提到的技术应同时应用;每个都用作另一个的交叉检查。分解技术采用分而治之的方法来进行软件项目评估。通过将项目分解为主要功能和相关的软件工程活动,可以逐步进行成本和工作量估算。

The remaining options are viable approaches to software project estimation. Ideally, the techniques noted for each option should be applied in tandem; each used as a cross-check for the other. Decomposition techniques take a divide-and-conquer approach to software project estimation. By decomposing a project into major functions and related software engineering activities, cost and effort estimation can be performed in a stepwise fashion.

计算机软件的经验估计模型使用从现有项目数据导出的公式来预测作为 LOC 或 FP 等函数的工作量。7 LOC 或 FP 的值使用第 25.6.3和25.6.4中描述的方法进行估计。但不使用这些部分中描述的表格,而是将 LOC 或 FP 的结果值插入估计模型 [Whi15]。

An empirical estimation model for computer software uses formulas derived from existing project data to predict effort as a function of things like LOC or FP.7 Values for LOC or FP are estimated using the approach described in Sections 25.6.3 and 25.6.4. But instead of using the tables described in those sections, the resultant values for LOC or FP are plugged into the estimation model [Whi15].

典型的经验估计模型是通过对从过去的软件项目收集的数据进行回归分析而得出的。此类模型的整体结构采用 [Mat94] 的形式

A typical empirical estimation model is derived using regression analysis on data collected from past software projects. The overall structure of such models takes the form [Mat94]

E = A + B × ( e v ) C (25.1)

E = A + B × (ev)C (25.1)

其中A、BC是根据经验得出的常数,E是以人月为单位的工作量,e v是估计变量(LOC 或 FP)。除了等式(25.1)中指出的关系之外,大多数估计模型都具有某种形式的项目调整组件,使E能够根据其他项目特征(例如问题复杂性、员工经验、开发环境)进行调整。

where A, B, and C are empirically derived constants, E is effort in person-months, and ev is the estimation variable (either LOC or FP). In addition to the relationship noted in Equation (25.1), the majority of estimation models have some form of project adjustment component that enables E to be adjusted by other project characteristics (e.g., problem complexity, staff experience, development environment).

经验估计模型可用于补充分解技术,并本身提供一种具有潜在价值的估计方法。模型基于经验(历史数据)并采用以下形式

Empirical estimation models can be used to complement decomposition techniques and offer a potentially valuable estimation approach in their own right. A model is based on experience (historical data) and takes the form

d = f ( v i )

d = f(vi)

其中d是多个估计值(例如,工作量、成本、项目持续时间)之一,vi是选定的独立参数(例如,估计的代码行数)。支持大多数软件估算模型的经验数据来自有限的项目样本。8因此,没有一种评估模型适用于所有类别的软件和所有开发环境。第511页

where d is one of a number of estimated values (e.g., effort, cost, project duration) and vi are selected independent parameters (e.g., estimated lines of code). The empirical data that support most software estimation models are derived from a limited sample of projects.8 For this reason, no estimation model is appropriate for all classes of software and in all development environments.Page 511

理想情况下,任何估算模型都应进行校准以反映当地条件。应通过应用从已完成项目收集的数据、将数据插入模型,然后将实际结果与预测结果进行比较来测试模型。如果一致性较差,则必须对模型进行调整并重新测试才能使用。

Ideally, any estimation model should be calibrated to reflect local conditions. The model should be tested by applying data collected from completed projects, plugging the data into the model, and then comparing actual to predicted results. If agreement is poor, the model must be tuned and retested before it can be used.

每种软件估算方法的效果取决于用于估算的历史数据。如果没有历史数据,估计的基础就非常不稳定。因此,您应该明智地使用从此类模型获得的结果。在第 23 章中,我们研究了一些为历史估计数据提供基础的软件指标或数据分析的特征。本书附录 2简要讨论了软件数据分析概念。

Each of the software estimation methods is only as good as the historical data used to seed the estimate. If no historical data exist, the estimates rest on a very shaky foundation. Therefore, you should use the results obtained from such models judiciously. In Chapter 23, we examined the characteristics of some of the software metrics or data analytics that provide the basis for historical estimation data. Software data analytics concepts are discussed briefly in Appendix 2 of this book.

25.6 分解和估计技术

25.6 Decomposition and Estimation Techniques

软件项目估算是问题解决的一种形式,在大多数情况下,要解决的问题(即,为软件项目制定成本和工作量估算)过于复杂,无法整体考虑。因此,您应该分解问题,将其重新描述为一组更小的(并且希望更易于管理的)问题。

Software project estimation is a form of problem solving, and in most cases, the problem to be solved (i.e., developing a cost and effort estimate for a software project) is too complex to be considered in one piece. For this reason, you should decompose the problem, recharacterizing it as a set of smaller (and hopefully, more manageable) problems.

第24章从两个不同的角度讨论了分解方法:问题分解和过程分解。估计使用一种或两种划分形式。但在进行估计之前,您必须了解要构建的软件的范围并对其“大小”进行估计。

In Chapter 24, the decomposition approach was discussed from two different points of view: decomposition of the problem and decomposition of the process. Estimation uses one or both forms of partitioning. But before an estimate can be made, you must understand the scope of the software to be built and generate an estimate of its “size.”

25.6.1 软件规模调整

25.6.1 Software Sizing

软件项目估算的准确性取决于许多因素:(1) 您正确估算要构建的产品规模的程度,(2) 将规模估算转化为人力、日历的能力时间和金钱(过去项目中可靠软件指标可用性的函数),(3) 项目计划反映软件团队能力的程度,以及 (4) 产品需求和环境的稳定性支持软件工程工作。

The accuracy of a software project estimate is predicated on a number of things: (1) the degree to which you have properly estimated the size of the product to be built, (2) the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects), (3) the degree to which the project plan reflects the abilities of the software team, and (4) the stability of product requirements and the environment that supports the software engineering effort.

由于项目估算的好坏取决于对要完成的工作规模的估算,因此软件规模调整是您作为规​​划者面临的第一个主要挑战。在项目规划的背景下,规模是指软件项目的可量化结果。如果采用直接方法,则可以以代码行数 (LOC) 来衡量大小。如果选择间接方法,则大小表示为功能点 (FP)。可以通过考虑项目的类型及其应用领域、交付的功能(即功能点的数量)、要交付的组件(或用例)的数量以及一组现有的程度来估计规模。必须针对新系统修改组件。第512页

Because a project estimate is only as good as the estimate of the size of the work to be accomplished, software sizing represents your first major challenge as a planner. In the context of project planning, size refers to a quantifiable outcome of the software project. If a direct approach is taken, size can be measured in lines of code (LOC). If an indirect approach is chosen, size is represented as function points (FP). Size can be estimated by considering the type of project and its application domain, the functionality delivered (i.e., the number of function points), the number of components (or use cases) to be delivered, and the degree to which a set of existing components must be modified for the new system.Page 512

25.6.2 基于问题的估计

25.6.2 Problem-Based Estimation

第 23 章中,代码行和功能点被描述为可以计算生产力指标的度量。LOC 和 FP 数据在软件项目估算期间以两种方式使用:(1) 作为估算变量来“调整”软件的每个元素;(2) 作为从过去项目收集的基线指标,并与估算变量结合使用来制定成本和努力预测。

In Chapter 23, lines of code and function points were described as measures from which productivity metrics can be computed. LOC and FP data are used in two ways during software project estimation: (1) as estimation variables to “size” each element of the software and (2) as baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort projections.

LOC 和 FP 估计是不同的估计技术。然而两者都有许多共同特征。您从软件范围的有界声明开始,并从该声明尝试将范围声明分解为每个都可以单独估计的问题函数。然后为每个函数估计 LOC 或 FP(估计变量)。或者,您可以选择其他组件来调整大小,例如类或对象、更改或受影响的业务流程。

LOC and FP estimation are distinct estimation techniques. Yet both have a number of characteristics in common. You begin with a bounded statement of software scope and from this statement attempt to decompose the statement of scope into problem functions that can each be estimated individually. LOC or FP (the estimation variable) is then estimated for each function. Alternatively, you may choose another component for sizing, such as classes or objects, changes, or business processes affected.

然后将基线生产率度量(例如,LOC/pm 或FP/pm)9应用于适当的估计变量,并导出该功能的成本或工作量。功能估计被组合起来以产生整个项目的总体估计。在收集项目的生产力指标时,请务必建立项目类型的分类法。这将使您能够计算特定领域的平均值,从而使估计更加准确。许多现代应用程序驻留在网络上或者是客户端-服务器体系结构的一部分。因此,请确保您的估算包括开发“基础设施”软件所需的工作量。

Baseline productivity metrics (e.g., LOC/pm or FP/pm)9 are then applied to the appropriate estimation variable, and cost or effort for the function is derived. Function estimates are combined to produce an overall estimate for the entire project. When collecting productivity metrics for projects, be sure to establish a taxonomy of project types. This will enable you to compute domain-specific averages, making estimation more accurate. Many modern applications reside on a network or are part of a client-server architecture. Therefore, be sure that your estimates include the effort required to develop “infrastructure” software.

25.6.3 基于 LOC 的估计示例

25.6.3 An Example of LOC-Based Estimation

作为 LOC 估计技术的一个例子,我们考虑为机械部件的计算机辅助设计应用程序开发一个软件包。该软件在笔记本电脑上执行。可以制定软件范围的初步声明:

As an example of an LOC estimation technique, we consider a software package to be developed for a computer-aided design application for mechanical components. The software is to execute on a notebook computer. A preliminary statement of software scope can be developed:

机械 CAD 软件将接受设计师提供的二维和三维几何数据。设计人员将通过用户界面交互和控制 CAD 系统,该用户界面将展现良好的人机界面设计的特征。所有几何数据和其他支持信息都将保存在 CAD 数据库中。将开发设计分析模块以产生所需的输出,这些输出将显示在各种设备上。该软件将设计用于控制外围设备并与之交互,包括触摸板、扫描仪、激光打印机和大床数字绘图仪。

The mechanical CAD software will accept two- and three-dimensional geometric data from a designer. The designer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of devices. The software will be designed to control and interact with peripheral devices that include a touchpad, scanner, laser printer, and large-bed digital plotter.

该范围声明是初步的,没有限制。每个句子都必须扩展以提供具体的细节和定量的界限。例如,在开始估算之前,规划人员必须确定“良好人机界面设计的特征”的含义或“CAD 数据库”的大小和复杂程度。

This statement of scope is preliminary—it is not bounded. Every sentence would have to be expanded to provide concrete detail and quantitative bounding. For example, before estimation can begin, the planner must determine what “characteristics of good human/machine interface design” means or what the size and sophistication of the “CAD database” are to be.

出于我们的目的,假设已经进行了进一步的细化,并且确定了图 25.2中列出的主要软件功能。根据 LOC 的分解技术,开发了一个估计表(图 25.2 )。为每个功能开发了一系列 LOC 估计值。例如,3D几何分析函数的LOC估计范围是乐观的,为4600 LOC;最有可能的是 6900 LOC;悲观的是 8600 LOC。应用方程(25.1),3D几何分析函数的预期值为6800 LOC。其他估计也以类似的方式得出。通过在估计的 LOC 列中垂直求和,为 CAD 系统建立了 33200 行代码的估计。第513页

For our purposes, assume that further refinement has occurred and that the major software functions listed in Figure 25.2 are identified. Following the decomposition technique for LOC, an estimation table (Figure 25.2) is developed. A range of LOC estimates is developed for each function. For example, the range of LOC estimates for the 3D geometric analysis function is optimistic, 4600 LOC; most likely, 6900 LOC; and pessimistic, 8600 LOC. Applying Equation (25.1), the expected value for the 3D geometric analysis function is 6800 LOC. Other estimates are derived in a similar fashion. By summing vertically in the estimated LOC column, an estimate of 33200 lines of code is established for the CAD system.Page 513

图25.2 LOC 方法的估计

Figure 25.2 Estimation table for the LOC methods

对历史数据的回顾表明,此类系统的组织平均生产率为 620 LOC/pm。按照每月 8,000 美元的负担人工费率计算,每行代码的成本约为 13 美元。根据 LOC 估算和历史生产力数据,预计项目总成本为 431,000 美元,预计工作量为 54 人月。10不要屈服于使用此结果作为项目估算的诱惑。您应该使用不同的方法得出另一个结果。

A review of historical data indicates that the organizational average productivity for systems of this type is 620 LOC/pm. Based on a burdened labor rate of $8,000 per month, the cost per line of code is approximately $13. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-months.10 Do not succumb to the temptation to use this result as your project estimate. You should derive another result using a different approach.

25.6.4 基于 FP 估计的示例

25.6.4 An Example of FP-Based Estimation

基于 FP 的估计的分解侧重于信息域值而不是软件功能。参考表 25.1,您可以估计 CAD 软件的输入、输出、查询、文件和外部接口。要计算FP 方程中所需的计数总计:

Decomposition for FP-based estimation focuses on information domain values rather than software functions. Referring to Table 25.1, you would estimate inputs, outputs, inquiries, files, and external interfaces for the CAD software. To compute the count total needed in the FP equation:

FP估计= 计数总计 × [0.65 + 0.01 × Σ( F i )]

FPestimated = count total × [0.65 + 0.01 × Σ(Fi)]

出于此估计的目的,假设复杂性权重因子是平均值。表 25.1列出了该估计的结果,FP 计数总数为 320。

For the purposes of this estimate, the complexity weighting factor is assumed to be average. Table 25.1 presents the results of this estimate, and the FP count total is 320.

为了计算 Σ( F i )的值,表 25.2中列出的 14 个复杂性权重因子中的每一个都使用 0(不重要)和 5(非常重要)之间的值进行评分。

To compute a value for Σ(Fi), each of the 14 complexity weighting factors listed in Table 25.2 is scored with a value between 0 (not important) and 5 (very important).

复杂性因子 Σ( F i )的这些评级之和为 52。因此调整因子的值为 1.17:

The sum of these ratings for the complexity factors Σ(Fi) is 52. So the value of the adjustment factor is 1.17:

[0.65 + 0.01 × Σ( F i )] = 1.17

[0.65 + 0.01 × Σ(Fi)] = 1.17

最后得出FP的估计数量:

Finally, the estimated number of FP is derived:

FP估计= 计数总计 × [0.65 + 0.01 × Σ( F i )] = 375

FPestimated = count total × [0.65 + 0.01 × Σ(Fi)] = 375

第515页此类系统的组织平均生产率为 6.5 FP/pm。根据每月 8,000 美元的负担劳动力费率,每个 FP 的成本约为 1,230 美元。根据 FP 估算和历史生产力数据,预计项目总成本为 461,000 美元,预计工作量为 58 人月。

Page 515The organizational average productivity for systems of this type is 6.5 FP/pm. Based on a burdened labor rate of $8,000 per month, the cost per FP is approximately $1,230. Based on the FP estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months.

25.6.5 基于过程的估计示例

25.6.5 An Example of Process-Based Estimation

估算项目的最常见技术是根据将使用的流程进行估算。也就是说,该过程被分解为一组相对较小的活动、操作和任务,并且估计完成每个活动、操作和任务所需的工作量。

The most common technique for estimating a project is to base the estimate on the process that will be used. That is, the process is decomposed into a relatively small set of activities, actions, and tasks and the effort required to accomplish each is estimated.

与基于问题的技术一样,基于过程的评估首先从项目范围中获得软件功能的描述。必须为每个功能执行一系列框架活动。功能和相关框架活动11可以表示为类似于图 25.3中所示的表格的一部分。

Like the problem-based techniques, process-based estimation begins with a delineation of software functions obtained from the project scope. A series of framework activities must be performed for each function. Functions and related framework activities11 may be represented as part of a table similar to the one presented in Figure 25.3.

图25.3 基于过程的估算

Figure 25.3 Process-based estimation table

一旦问题功能和流程活动融合在一起,您就可以估计完成每个软件功能的每个软件流程活动所需的工作量(例如,人月)。这些数据构成了图 25.3表格的中心矩阵。然后将平均人工费率(即成本/单位工作量)应用于每个流程活动的估计工作量。第516页

Once problem functions and process activities are melded, you estimate the effort (e.g., person-months) that will be required to accomplish each software process activity for each software function. These data constitute the central matrix of the table in Figure 25.3. Average labor rates (i.e., cost/unit effort) are then applied to the effort estimated for each process activity.Page 516

为了说明基于过程的估计的使用,我们再次考虑第 25.6.3 节中介绍的 CAD 软件。系统配置和所有软件功能保持不变,并以项目范围表示。

To illustrate the use of process-based estimation, we again consider the CAD software introduced in Section 25.6.3. The system configuration and all software functions remain unchanged and are indicated by project scope.

参考图 25.3中所示的基于流程的完整表格,为每个 CAD 软件功能提供了每个软件工程活动的工作量估计(以人月为单位)(为简洁起见,进行了缩写)。工程和构建发布活动被细分为所示的主要软件工程任务。为客户沟通、规划和风险分析提供工作量的总体估计。这些都记录在表底部的总行中。水平和垂直总计提供了分析、设计、编码和测试所需的估计工作量的指示。应该指出的是,大约 53% 的工作都花费在前端工程任务(需求分析和设计)上,表明这项工作的相对重要性。

Referring to the completed process-based table shown in Figure 25.3, estimates of effort (in person-months) for each software engineering activity are provided for each CAD software function (abbreviated for brevity). The engineering and construction release activities are subdivided into the major software engineering tasks shown. Gross estimates of effort are provided for customer communication, planning, and risk analysis. These are noted in the total row at the bottom of the table. Horizontal and vertical totals provide an indication of estimated effort required for analysis, design, code, and test. It should be noted that approximately 53 percent of all effort is expended on front-end engineering tasks (requirements analysis and design), indicating the relative importance of this work.

根据每月 8,000 美元的平均劳动力负担率,预计项目总成本为 368,000 美元,预计工作量为 46 人月。如果需要,人工费率可以与每个框架活动或软件工程任务相关联并单独计算。第517页

Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months. If desired, labor rates could be associated with each framework activity or software engineering task and computed separately.Page 517

25.6.6 使用用例点进行估计的示例

25.6.6 An Example of Estimation Using Use Case Points

正如我们在本书第二部分中所指出的,用例为软件团队提供了对软件范围和需求的洞察。一旦开发了用例,它们就可以用来估计软件项目的预计“规模”。用例不解决所描述的功能和特性的复杂性,并且它们可以描述涉及许多功能和特性的复杂行为(例如,交互)。即使有这些限制,也可以以类似于功能点计算的方式计算用例点(UCP)(第 25.6 节)。

As we have noted throughout Part Two of this book, use cases provide a software team with insight into software scope and requirements. Once use cases have been developed, they can be used to estimate the projected “size” of a software project. Use cases do not address the complexity of the functions and features that are described, and they can describe complex behavior (e.g., interactions) that involve many functions and features. Even with these constraints, it is possible to compute use case points (UCPs) in a manner that is analogous to the computation of functions points (Section 25.6).

Cohn [Coh05] 指出用例点的计算必须考虑以下特征:

Cohn [Coh05] indicates that the computation of use case points must take the following characteristics into account:

  • 系统中用例的数量和复杂性。

  • The number and complexity of the use cases in the system.

  • 系统中参与者的数量和复杂性。

  • The number and complexity of the actors on the system.

  • 未编写为用例的各种非功能性需求(例如可移植性、性能、可维护性)。

  • Various nonfunctional requirements (such as portability, performance, maintainability) that are not written as use cases.

  • 项目开发的环境(例如,编程语言、软件团队的动机)。

  • The environment in which the project will be developed (e.g., the programming language, the software team’s motivation).

首先,评估每个用例以确定其相对复杂性。简单用例表示简单的用户界面、单个数据库以及三个或更少的事务以及五个或更少的类实现。平均用例表示更复杂的 UI、两个或三个数据库以及 5 到 10 个类的四到七个事务。最后,复杂的用例意味着具有多个数据库的复杂 UI,使用 8 个或更多事务和 11 个或更多类。每个用例均使用这些标准进行评估,并且每种类型的计数分别按 5、10 和 15 因子进行加权。未调整用例总权重( UUCW) 是所有加权计数的总和 [Nun11]。

To begin, each use case is assessed to determine its relative complexity. A simple use case indicates a simple user interface, a single database, and three or fewer transactions and five or fewer class implementations. An average use case indicates a more complex UI, two or three databases, and four to seven transactions with 5 to 10 classes. Finally, a complex use case implies a complex UI with multiple databases, using eight or more transactions and 11 or more classes. Each use case is assessed using these criteria and the count of each type is weighted by a factor of 5, 10, and 15, respectively. A total unadjusted use case weight (UUCW) is the sum of all weighted counts [Nun11].

接下来,对每个演员进行评估。简单参与者是通过 API 进行通信的自动机(另一个系统、机器或设备)。普通参与者是通过协议或数据存储进行通信的自动机,复杂参与者是通过 GUI 或其他人机界面进行通信的人类。使用这些标准对每个参与者进行评估,并且每种类型的计数分别按 1、2 和 3 因子进行加权。未调整的演员总权重(UAW) 是所有加权计数的总和。

Next, each actor is assessed. Simple actors are automatons (another system, a machine or device) that communicate through an API. Average actors are automatons that communicate through a protocol or a data store, and complex actors are humans who communicate through a GUI or other human interface. Each actor is assessed using these criteria, and the count of each type is weighted by a factor of 1, 2, and 3, respectively. The total unadjusted actor weight (UAW) is the sum of all weighted counts.

通过考虑技术复杂性因素(TCF)和环境复杂性因素(ECF)来修改这些未调整的值。十三个因素有助于评估最终 TCF,八个因素有助于计算最终 ECF [Coh05]。一旦确定了这些值,最终的 UCP 值将按以下方式计算:

These unadjusted values are modified by considering technical complexity factors (TCFs) and environment complexity factors (ECFs). Thirteen factors contribute to an assessment of the final TCF, and eight factors contribute to the computation of the final ECF [Coh05]. Once these values have been determined, the final UCP value is computed in the following manner:

UCP = (UUCW + UAW) × TCF × ECF(25.2)

UCP = (UUCW + UAW) × TCF × ECF (25.2)

25.6.3节中介绍的CAD软件由三个子系统组组成:用户界面子系统(包括UICF)、工程子系统组(包括2DGA、3DGA和DAM子系统)和基础设施子系统组(包括CGDF和PCF子系统) 。十六个复杂的用例描述了用户界面子系统。工程子系统组由 14 个普通用例和 8 个简单用例描述。并通过 10 个简单的用例描述了基础设施子系统。所以,第518页

The CAD software introduced in Section 25.6.3 is composed of three subsystem groups: user interface subsystem (includes UICF), engineering subsystem group (includes the 2DGA, 3DGA, and DAM subsystems), and infrastructure subsystem group (includes CGDF and PCF subsystems). Sixteen complex use cases describe the user interface subsystem. The engineering subsystem group is described by 14 average use cases and 8 simple use cases. And the infrastructure subsystem is described with 10 simple use cases. Therefore,Page 518

UUCW = (16 个用例 × 15) + [(14 个用例 × 10) + (8 个用例 × 5)] + (10 个用例 × 5) = 470

UUCW = (16 use cases × 15) + [(14 use cases × 10) + (8 use cases × 5)] + (10 use cases × 5) = 470

对用例的分析表明,有 8 个简单参与者、12 个普通参与者和 4 个复杂参与者。所以,

Analysis of the use cases indicates that there are 8 simple actors, 12 average actors, and 4 complex actors. Therefore,

UAW = (8 名演员 × 1) + (12 名演员 × 2) + (4 名演员 × 3) = 44

UAW = (8 actors × 1) + (12 actors × 2) + (4 actors × 3) = 44

经过技术和环境评估后,

After evaluation of the technology and the environment,

TCF = 1.04

TCF = 1.04

有效系数=0.96

ECF = 0.96

使用方程(25.2)

Using Equation (25.2),

UCP = (470 + 44) × 1.04 × 0.96 = 513

UCP = (470 + 44) × 1.04 × 0.96 = 513

以过去的项目数据为指导,开发小组为每个 UCP 制作了 85 个 LOC。因此,CAD 项目的总体规模估计为 43600 LOC。可以对应用的工作量或项目持续时间进行类似的计算。

Using past project data as a guide, the development group has produced 85 LOC per UCP. Therefore, an estimate of the overall size of the CAD project is 43600 LOC. Similar computations can be made for applied effort or project duration.

使用 620 LOC/pm 作为此类系统的平均生产率以及每月 8,000 美元的人工负担,每行代码的成本约为 13 美元。根据用例估算和历史生产力数据,预计项目总成本为 552,000 美元,预计工作量约为 70 人月。

Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8,000 per month, the cost per line of code is approximately $13. Based on the use case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated effort is about 70 person-months.

25.6.7 协调估计

25.6.7 Reconciling Estimates

任何估计技术,无论多么复杂,都必须通过使用不同方法计算至少一个其他估计来进行检查。如果您独立创建了两个或三个估算,那么您现在就有两个或三个成本和工作量估算需要比较和协调。如果两组估计显示出合理的一致性,则有充分的理由相信这些估计是可靠的。另一方面,如果这些分解技术的结果几乎没有一致,则必须进行进一步的调查和分析。

Any estimation technique, no matter how sophisticated, must be checked by computing at least one other estimate using a different approach. If you have created two or three estimates independently, you now have two or three estimates for cost and effort that need to be compared and reconciled. If both sets of estimates show reasonable agreement, there is good reason to believe that the estimates are reliable. If, on the other hand, the results of these decomposition techniques show little agreement, further investigation and analysis must be conducted.

当您的估计相差很大时,您需要重新评估用于进行估计的信息。估计结果大相径庭通常可以归因于以下两个原因之一:(1) 项目范围没有被规划者充分理解或误解,或者 (2) 用于基于问题的估计技术的生产率数据不适合项目的实际情况。申请或被误用。您应该确定差异的原因,然后重新计算这些估计值。

When your estimates are far apart, you need to reevaluate the information used to make the estimates. Widely divergent estimates can often be traced to one of two causes: (1) the scope of the project is not adequately understood or has been misinterpreted by the planner, or (2) productivity data used for problem-based estimation techniques is inappropriate for the application or has been misapplied. You should determine the cause of divergence and then recompute these estimates.

前面几节中讨论的估算技术产生了多个估算,应该对这些估算进行协调,以生成对工作量、项目持续时间或成本的单一估算。CAD 软件的总估计工作量(第 25.6.3 节)范围从低的 46 人月(使用基于流程的估计方法得出)到高的 68 人月(使用用例估计得出)。所有四个估计值的简单平均值为 56 人月。但是,当最高估计值和最低估计值相差 21 人月时,这是最好的方法吗?

The estimation techniques discussed in the preceding sections resulted in multiple estimates that should be reconciled to produce a single estimate of effort, project duration, or cost. The total estimated effort for the CAD software (Section 25.6.3) ranges from a low of 46 person-months (derived using a process-based estimation approach) to a high of 68 person-months (derived with use case estimation). The simple average of all four estimates is 56 person-months. But is this the best approach when the high and low estimates are 21 person-months apart?

第519页一种方法可以是基于将高估计称为悲观估计、将低估计称为乐观估计以及将中间值称为最可能值来计算加权平均值。然后可以计算三点值或期望值。估计变量(大小)S的预期可以计算为乐观 ( s opt )、最可能 ( s m ) 和悲观 ( s pess ) 估计的加权平均值。例如,

Page 519One approach may be to compute a weighted average, based on calling a high estimate a pessimistic estimate, a low estimate an optimistic estimate, and an in-between value a most likely value. A three-point or expected value can then be computed. The expected value for the estimation variable (size) S can be computed as a weighted average of the optimistic (sopt), most likely (sm), and pessimistic (spess) estimates. For example,

(25.3)

(25.3)

对“最有可能”的估计给予最大程度的信任,并遵循贝塔概率分布。我们假设实际规模结果超出乐观或悲观值的可能性很小。

gives heaviest credence to the “most likely” estimate and follows a beta probability distribution. We assume that there is a very small probability the actual size result will fall outside the optimistic or pessimistic values.

一旦确定了估计变量的预期值,就应该检查历史生产率数据。我们的估计看起来正确吗?这个问题唯一合理的答案是,我们不能确定。即便如此,常识和经验也必须占上风。

Once the expected value for the estimation variable has been determined, historical productivity data should be examined. Do our estimates seem correct? The only reasonable answer to this question is, we can’t be sure. Even then, common sense and experience must prevail.

25.6.8 敏捷开发的估算

25.6.8 Estimation for Agile Development

因为敏捷项目的需求(第 3 章)是由一组用户故事定义的,所以可以在每个软件增量的项目规划背景下开发一种非正式的、合理的、有意义的估计方法。敏捷项目的估算使用分解方法,包括以下步骤:

Because the requirements for an agile project (Chapter 3) are defined by a set of user stories, it is possible to develop an estimation approach that is informal, reasonably disciplined, and meaningful within the context of project planning for each software increment. Estimation for agile projects uses a decomposition approach that encompasses the following steps:

  1. 1.每个用户故事(相当于最终用户或其他利益相关者在项目一开始创建的迷你用例)都被单独考虑以用于估计目的。
  2. 1.Each user story (the equivalent of a mini use case created at the very start of a project by end users or other stakeholders) is considered separately for estimation purposes.
  3. 2. 用户故事被分解为开发它所需的一组软件工程任务。
  4. 2. The user story is decomposed into the set of software engineering tasks that will be required to develop it.
  5. 3a. 每项任务都是单独估计的。注意:估计可以基于历史数据、经验模型或“经验”(例如,使用计划扑克等技术,第 7.2.3 节)。
  6. 3a. Each task is estimated separately. Note: Estimation can be based on historical data, an empirical model, or “experience” (e.g., using a technique like planning poker, Section 7.2.3).
  7. 3b. 或者,用户故事的“体积”可以用 LOC、FP 或一些其他面向体积的度量(例如,用例计数)来估计。
  8. 3b. Alternatively, the “volume” of the user story can be estimated in LOC, FP, or some other volume-oriented measure (e.g., use case count).
  9. 4a. 将每个任务的估计相加,以创建用户故事的估计。
  10. 4a. Estimates for each task are summed to create an estimate for the user story.
  11. 4b. 或者,使用历史数据将用户故事的数量估计转化为工作量。
  12. 4b. Alternatively, the volume estimate for the user story is translated into effort using historical data.
  13. 5. 将针对给定软件增量实现的所有用户故事的工作量估计相加,以开发增量的工作量估计。
  14. 5. The effort estimates for all user stories that are to be implemented for a given software increment are summed to develop the effort estimate for the increment.

由于开发软件增量所需的项目持续时间很短(通常为 3 至 6 周),因此这种估算方法有两个目的:(1)确定增量中包含的场景数量符合(2) 建立增量开发过程中分配工作量的基础。

Because the project duration required for the development of a software increment is quite short (typically 3 to 6 weeks), this estimation approach serves two purposes: (1) to be certain that the number of scenarios to be included in the increment conforms to the available resources, and (2) to establish a basis for allocating effort as the increment is developed.

第 520 页

Page 520

25.7 项目调度

25.7 Project Scheduling

软件项目调度是一种通过将工作量分配给特定软件工程任务来在计划的项目持续时间内分配估计工作量的活动。然而,值得注意的是,时间表会随着时间的推移而变化。在项目规划的早期阶段,制定了宏观时间表。这种类型的进度表确定了所有主要流程框架活动以及它们所应用的产品功能。随着项目的开展,宏观进度表中的每一项都会细化为详细的进度表。在这里,确定并安排特定的软件操作和任务(完成活动所需的)。

Software project scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. It is important to note, however, that the schedule evolves over time. During early stages of project planning, a macroscopic schedule is developed. This type of schedule identifies all major process framework activities and the product functions to which they are applied. As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule. Here, specific software actions and tasks (required to accomplish an activity) are identified and scheduled.

尽管软件延迟交付的原因有很多,但大多数都可以追溯到以下一个或多个根本原因:

Although there are many reasons why software is delivered late, most can be traced to one or more of the following root causes:

  • 软件团队之外的某个人设定了一个不切实际的截止日期,并强加给团队的经理和从业人员。

  • An unrealistic deadline established by someone outside the software team and forced on managers and practitioners on the group.

  • 客户要求的变化未反映在计划变更中。

  • Changing customer requirements that are not reflected in schedule changes.

  • 诚实地低估了完成这项工作所需的工作量和/或资源数量。

  • An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job.

  • 项目开始时未考虑的可预测和/或不可预测的风险。

  • Predictable and/or unpredictable risks that were not considered when the project commenced.

  • 无法提前预见的技术困难。

  • Technical difficulties that could not have been foreseen in advance.

  • 人类的困难是无法提前预见的。

  • Human difficulties that could not have been foreseen in advance.

  • 项目人员之间沟通不畅导致延误。

  • Miscommunication among project staff that results in delays.

  • 项目管理层未能认识到项目落后于计划,并且缺乏纠正问题的行动。

  • A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem.

在软件行业中,过于激进(读作“不切实际”)的最后期限是一个令人不快的事实。有时,从设定最后期限的人的角度来看,这样的最后期限是出于合理的原因而被要求的。但常识告诉我们,合法性也必须被从事这项工作的人所感知。

Aggressive (read “unrealistic”) deadlines are an unpleasant fact in the software business. Sometimes such deadlines are demanded for reasons that are legitimate, from the point of view of the person who sets the deadline. But common sense says that legitimacy must also be perceived by the people doing the work.

本章讨论的估计方法和本节描述的调度技术通常是在定义的最后期限的约束下实现的。如果最佳估计表明截止日期不切实际,称职的项目经理应将其发现告知管理层和所有利益相关者,并提出替代方案以减轻错过截止日期造成的损害。

The estimation methods discussed in this chapter and the scheduling techniques described in this section are often implemented under the constraint of a defined deadline. If best estimates indicate that the deadline is unrealistic, a competent project manager should inform management and all stakeholders of her findings and suggest alternatives to mitigate the damage of missing the deadline.

技术项目(无论是为视频游戏构建虚拟世界还是开发操作系统)的现实情况是,必须执行数百个小任务才能完成更大的目标。其中一些任务不属于主流,可以完成而不必担心影响项目完成日期。其他任务位于关键路径上。如果这些“关键”任务落后于计划,整个项目的完成日期就会受到威胁。

The reality of a technical project (whether it involves building a virtual world for a video game or developing an operating system) is that hundreds of small tasks must occur to accomplish a larger goal. Some of these tasks lie outside the mainstream and may be completed without worry about the impact on the project completion date. Other tasks lie on the critical path. If these “critical” tasks fall behind schedule, the completion date of the entire project is put into jeopardy.

作为项目经理,您的目标是定义所有项目任务,构建一个描述其相互依赖性的网络,识别网络中的关键任务,然后跟踪其进度以确保“一天一次地”识别出延迟。 ” 为了实现这一目标,您必须有一个以一定程度的分辨率定义的时间表,以便监控进度并控制项目。实现项目经理制定计划和跟踪进度的需求所需的任务不应手动执行。有很多优秀的调度工具。一个好的经理会使用它们。第521页

As a project manager, your objective is to define all project tasks, build a network that depicts their interdependencies, identify the tasks that are critical within the network, and then track their progress to ensure that delay is recognized “one day at a time.” To accomplish this, you must have a schedule that has been defined at a degree of resolution that allows progress to be monitored and the project to be controlled. The tasks required to achieve a project manager’s needs to build a schedule and track progress should not be performed manually. There are many excellent scheduling tools. A good manager uses them.Page 521

25.7.1 基本原则

25.7.1 Basic Principles

软件工程项目的调度可以从两个截然不同的角度来看待。首先,基于计算机的系统的发布结束日期已经(且不可撤销)确定。软件组织必须在规定的时间范围内分配工作量。软件调度的第二种观点假设已经讨论了粗略的时间范围,但结束日期是由软件工程组织设定的。努力分配以充分利用资源,并在仔细分析软件后确定结束日期。不幸的是,第一种情况比第二种情况更常见。

Scheduling for software engineering projects can be viewed from two rather different perspectives. In the first, an end date for release of a computer-based system has already (and irrevocably) been established. The software organization is constrained to distribute effort within the prescribed time frame. The second view of software scheduling assumes that rough chronological bounds have been discussed but that the end date is set by the software engineering organization. Effort is distributed to make best use of resources, and an end date is defined after careful analysis of the software. Unfortunately, the first situation is encountered far more frequently than the second.

与软件工程的所有其他领域一样,有一些基本原则指导软件项目调度:

Like all other areas of software engineering, a number of basic principles guide software project scheduling:

  • 区隔化。项目必须划分为许多可管理的活动和任务。为了实现划分,产品和过程都被分解。

  • Compartmentalization. The project must be compartmentalized into a number of manageable activities and tasks. To accomplish compartmentalization, both the product and the process are decomposed.

  • 相互依存。必须确定每个划分的活动或任务的相互依赖性。有些任务必须按顺序发生,而另一些任务可以并行发生。有些活动只有在其他活动产生的工作产品可​​用后才能开始。其他活动可以独立进行。

  • Interdependency. The interdependency of each compartmentalized activity or task must be determined. Some tasks must occur in sequence, while others can occur in parallel. Some activities cannot commence until the work product produced by another is available. Other activities can occur independently.

  • 时间分配。必须为每个要安排的任务分配一定数量的工作单位(例如,人日工作量)。此外,必须为每项任务分配一个开始日期和完成日期,该日期是相互依赖性以及工作是否全职或兼职进行的函数。

  • Time allocation. Each task to be scheduled must be allocated some number of work units (e.g., person-days of effort). In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time basis.

  • 努力验证。每个项目的软件团队都有一定数量的人员。在进行时间分配时,您必须确保在任何给定时间安排的人数不超过分配的人数。例如,考虑一个分配了三名软件工程师的项目(例如,每天分配的工作量可用三个人日)。12在某一天,必须同时完成七项任务。每项任务需要 0.50 人日的努力。分配的精力比完成这项工作的人员还要多。

  • Effort validation. Every project has a defined number of people on the software team. As time allocation occurs, you must ensure that no more than the allocated number of people has been scheduled at any given time. For example, consider a project that has three assigned software engineers (e.g., three person-days are available per day of assigned effort).12 On a given day, seven concurrent tasks must be accomplished. Each task requires 0.50 person-days of effort. More effort has been allocated than there are people to do the work.

  • 明确的职责。计划的每项任务都应分配给特定的团队成员。

  • Defined responsibilities. Every task that is scheduled should be assigned to a specific team member.

  • 明确的结果。计划的每项任务都应该有明确的结果。对于软件项目,结果通常是工作产品(例如,组件的设计)或工作产品的一部分。工作产品通常合并在可交付成果中。

  • Defined outcomes. Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product (e.g., the design of a component) or a part of a work product. Work products are often combined in deliverables.

  • 定义的里程碑。每个任务或任务组都应与项目里程碑相关联。当一个或多个工作产品经过质量审查(第 15 章)并获得批准时,就完成了一个里程碑。

  • Defined milestones. Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality (Chapter 15) and has been approved.

这些原则中的每一个都随着项目进度的发展而应用。第522页

Each of these principles is applied as the project schedule evolves.Page 522

25.7.2 人与努力之间的关系

25.7.2 The Relationship Between People and Effort

许多负责软件开发工作的经理仍然相信一个常见的神话:“如果我们落后于计划,我们总是可以添加更多程序员并在项目后期赶上。” 不幸的是,在项目后期添加人员通常会对项目产生破坏性影响,导致进度进一步推迟。添加的人必须学习该系统,而教他们的人正是从事这项工作的人。一边教学,一边没有做任何工作,项目进一步落后。

There is a common myth that is still believed by many managers who are responsible for software development work: “If we fall behind schedule, we can always add more programmers and catch up later in the project.” Unfortunately, adding people late in a project often has a disruptive effect on the project, causing schedules to slip even further. The people who are added must learn the system, and the people who teach them are the same people who were doing the work. While teaching, no work is done, and the project falls further behind.

除了学习系统所花费的时间之外,更多的人还增加了整个项目中沟通路径的数量和沟通的复杂性。尽管沟通对于成功的软件开发绝对至关重要,但每条新的沟通路径都需要额外的努力,因此也需要额外的时间。如果您必须向后期项目添加人员,请确保为他们分配了高度划分的工作。

In addition to the time it takes to learn the system, more people increase the number of communication paths and the complexity of communication throughout a project. Although communication is absolutely essential to successful software development, every new communication path requires additional effort and therefore additional time. If you must add people to a late project, be sure that you’ve assigned them work that is highly compartmentalized.

多年来,经验数据和理论分析已经证明项目进度是有弹性的。也就是说,可以在一定程度上压缩期望的项目完成日期(通过添加额外的资源)。还可以延长完成日期(通过减少资源数量)。

Over the years, empirical data and theoretical analysis have demonstrated that project schedules are elastic. That is, it is possible to compress a desired project completion date (by adding additional resources) to some extent. It is also possible to extend a completion date (by reducing the number of resources).

Putnam -Norden-Rayleigh (PNR) 曲线13提供了软件项目所付出的努力与交付时间之间的关系的指示。曲线的一个版本表示项目工作量与交付时间的关系,如图 25.4所示。该曲线指示最小值to 其指示最低的交付成本(即,将导致花费最少努力的交付时间)。当我们向左移动时(,当我们试图加速交付时),曲线非线性上升

The Putnam-Norden-Rayleigh (PNR) curve13 provides an indication of the relationship between effort applied and delivery time for a software project. A version of the curve, representing project effort as a function of delivery time, is shown in Figure 25.4. The curve indicates a minimum value to that indicates the least cost for delivery (i.e., the delivery time that will result in the least effort expended). As we move left of to (i.e., as we try to accelerate delivery), the curve rises nonlinearly.

25.4努力与 交付时间之间的关系

Figure 25.4 The relationship between effort and delivery time

作为一个例子,我们假设项目团队已经估计了达到在进度和可用资源方面最佳的标称交付时间t d所需的工作量E d 。尽管可以加速交付,但曲线在t d左侧急剧上升。事实上,PNR 曲线表明项目交付时间不能压缩到超过 0.75 t d。如果我们尝试进一步压缩,项目就会进入“不可能的区域”,失败的风险会变得非常高。PNR 曲线还表明成本最低的递送选项t o = 2 t d。这里的含义是,延迟项目交付可以显着降低成本。当然,必须权衡与延迟相关的业务成本。第523页

As an example, we assume that a project team has estimated a level of effort Ed will be required to achieve a nominal delivery time td that is optimal in terms of schedule and available resources. Although it is possible to accelerate delivery, the curve rises very sharply to the left of td. In fact, the PNR curve indicates the project delivery time cannot be compressed much beyond 0.75td. If we attempt further compression, the project moves into “the impossible region” and risk of failure becomes very high. The PNR curve also indicates that the lowest cost delivery option to = 2td. The implication here is that delaying project delivery can reduce costs significantly. Of course, this must be weighed against the business cost associated with the delay.Page 523

引入的软件方程[Put92] 是从 PNR 曲线推导出来的,并演示了完成项目的时间顺序与项目所投入的人力之间的高度非线性关系。交付的代码行数(源语句)L与工作量和开发时间相关,公式如下:

The software equation [Put92] introduced is derived from the PNR curve and demonstrates the highly nonlinear relationship between chronological time to complete a project and human effort applied to the project. The number of delivered lines of code (source statements), L, is related to effort and development time by the equation:

L = P × E 1/3 t 4/3 (25.4)

L = P × E1/3t4/3 (25.4)

其中E是以人月为单位的开发工作量,P是生产力参数,反映了导致高质量软件工程工作的各种因素(P的典型值范围在 2000 到 12000 之间),t是日历中的项目持续时间几个月。

where E is development effort in person-months, P is a productivity parameter that reflects a variety of factors that leads to high-quality software engineering work (typical values for P range between 2000 and 12000), and t is the project duration in calendar months.

重新排列这个软件方程,我们可以得出开发工作量E的表达式:

Rearranging this software equation, we can arrive at an expression for development effort E:

(25.5)

(25.5)

其中E是软件开发和维护整个生命周期中花费的精力(以人年为单位),t是以年为单位的开发时间。发展努力的方程可以通过包含负担劳动率因素(美元/人年)与发展成本相关联。

where E is the effort expended (in person-years) over the entire life cycle for software development and maintenance and t is the development time in years. The equation for development effort can be related to development cost by the inclusion of a burdened labor rate factor ($/person-year).

这导致了一些有趣的结果。随着项目期限变得越来越紧,无论有多少人参与这项工作,您都会达到无法按计划完成工作的地步。面对现实并确定新的交货日期。

This leads to some interesting results. As a project deadline becomes tighter and tighter, you reach a point at which the work cannot be completed on schedule, regardless of the number of people doing the work. Face reality and define a new delivery date.

还考虑一个复杂的实时软件项目,估计需要 33000 LOC,需要 12 人年的努力。如果项目团队分配8人,则项目大约可在1.3年内完成。然而,如果我们将结束日期延长至 1.75 年,则方程 (25.5)中描述的模型的高度非线性性质将得出:

Consider also a complex, real-time software project estimated at 33000 LOC, 12 person-years of effort. If eight people are assigned to the project team, the project can be completed in approximately 1.3 years. If, however, we extend the end date to 1.75 years, the highly nonlinear nature of the model described in Equation (25.5) yields:

这意味着,通过将结束日期延长6个月,我们可以将人数从8人减少到4人!这些结果的有效性有待商榷,但含义很明确:通过在较长的时间内使用更少的人员来实现相同的目标,可以获得好处。

This implies that, by extending the end date by 6 months, we can reduce the number of people from eight to four! The validity of such results is open to debate, but the implication is clear: Benefit can be gained by using fewer people over a somewhat longer time span to accomplish the same objective.

25.8 定义项目任务集

25.8 Defining a Project Task Set

无论选择哪种流程模型,软件团队执行的工作都是通过一组任务来完成的,这些任务使您能够定义、开发并最终支持计算机软件。没有一个任务集适合所有项目。适合大型、复杂系统的任务集可能会被认为对于小型、相对简单的软件产品来说是多余的。因此,有效的软件过程应该定义一组任务集,每个任务集旨在满足不同类型项目的需求。第524页

Regardless of the process model that is chosen, the work that a software team performs is achieved through a set of tasks that enable you to define, develop, and ultimately support computer software. No single task set is appropriate for all projects. The set of tasks that would be appropriate for a large, complex system would likely be perceived as overkill for a small, relatively simple software product. Therefore, an effective software process should define a collection of task sets, each designed to meet the needs of different types of projects.Page 524

正如我们在第 2 章中提到的,任务集是完成特定项目必须完成的软件工程工作任务、里程碑、工作产品和质量保证过滤器的集合。任务集必须提供足够的纪律来实现高软件质量。但与此同时,它不能给项目团队带来不必要的工作负担。

As we noted in Chapter 2, a task set is a collection of software engineering work tasks, milestones, work products, and quality assurance filters that must be accomplished to complete a particular project. The task set must provide enough discipline to achieve high software quality. But, at the same time, it must not burden the project team with unnecessary work.

要制定项目进度表,必须在项目时间线上分配任务集。任务集将根据项目类型和软件团队决定开展工作的严格程度而有所不同。许多因素影响要选择的任务集。其中包括 [Pre05]:项目规模、潜在用户数量、任务关键性、应用程序寿命、需求稳定性、客户/开发人员沟通的便利性、适用技术的成熟度、性能限制、嵌入式和非嵌入式特征、项目人员以及再造因素。当结合起来考虑时,这些因素表明了软件过程应用的严格程度。

To develop a project schedule, a task set must be distributed on the project time line. The task set will vary depending upon the project type and the degree of rigor with which the software team decides to do its work. Many factors influence the task set to be chosen. These include [Pre05]: size of the project, number of potential users, mission criticality, application longevity, stability of requirements, ease of customer/developer communication, maturity of applicable technology, performance constraints, embedded and nonembedded characteristics, project staff, and reengineering factors. When taken in combination, these factors provide an indication of the degree of rigor with which the software process should be applied.

25.8.1 任务集示例

25.8.1 A Task Set Example

当必须探索某些新技术的潜力时,就会启动概念开发项目。不确定该技术是否适用,但客户(例如营销人员)相信存在潜在的好处。通过应用以下任务集来处理概念开发项目:

A concept development project is initiated when the potential for some new technology must be explored. There is no certainty that the technology will be applicable, but a customer (e.g., marketing) believes that potential benefit exists. Concept development projects are approached by applying the following task set:

  1. 1.1概念范围确定了项目的总体范围。
  2. 1.1Concept scoping determines the overall scope of the project.
  3. 1.2初步概念规划确定了组织承担项目范围所暗示工作的能力。
  4. 1.2Preliminary concept planning establishes the organization’s ability to undertake the work implied by the project scope.
  5. 1.3技术风险评估评估与作为项目范围一部分实施的技术相关的风险。
  6. 1.3Technology risk assessment evaluates the risk associated with the technology to be implemented as part of the project scope.
  7. 1.4概念验证证明了新技术在软件环境中的可行性。
  8. 1.4Proof of concept demonstrates the viability of a new technology in the software context.
  9. 1.5概念实施以客户可以审查的方式实施概念表示,并在必须将概念出售给其他客户或管理层时用于“营销”目的。
  10. 1.5Concept implementation implements the concept representation in a manner that can be reviewed by a customer and is used for “marketing” purposes when a concept must be sold to other customers or management.
  11. 1.6客户对该概念的反应征求对新技术概念的反馈,并针对特定的客户应用。
  12. 1.6Customer reaction to the concept solicits feedback on a new technology concept and targets specific customer applications.

快速浏览一下这些任务应该不会产生什么意外。事实上,概念开发项目(以及所有其他类型的项目)的软件工程流程只不过是常识。

A quick scan of these tasks should yield few surprises. In fact, the software engineering flow for concept development projects (and for all other types of projects as well) is little more than common sense.

25.8.2 细化主要任务

25.8.2 Refinement of Major Tasks

前一节中描述的主要任务(即软件工程操作)可用于定义项目的宏观时间表。然而,必须细化宏观进度以创建详细的项目进度。细化首先将每个主要任务分解为一组子任务(具有相关的工作产品和里程碑)。第 525 页

The major tasks (i.e., software engineering actions) described in the preceding section may be used to define a macroscopic schedule for a project. However, the macroscopic schedule must be refined to create a detailed project schedule. Refinement begins by taking each major task and decomposing it into a set of subtasks (with related work products and milestones).Page 525

作为任务分解的示例,请考虑任务 1.1,概念范围界定。任务细化可以使用大纲格式来完成,但在本书中,使用流程设计语言方法来说明概念范围界定活动的流程:

As an example of task decomposition, consider Task 1.1, Concept Scoping. Task refinement can be accomplished using an outline format, but in this book, a process design language approach is used to illustrate the flow of the concept scoping activity:

任务定义:任务 1.1 概念范围

Task definition: Task 1.1 Concept Scoping

  • 1.1.1 确定需求、利益和潜在客户;

  • 1.1.1 Identify need, benefits and potential customers;

  • 1.1.2 定义驱动应用程序所需的输出/控制和输入事件;

    • 开始任务 1.1.2

    • 1.1.2.1 TR:审查需求的书面描述14

    • 1.1.2.2 导出客户可见输出/输入列表

    • 1.1.2.3 TR:与客户一起审查输出/输入并根据需要进行修改;

    • 结束任务 任务 1.1.2

  • 1.1.2 Define desired output/control and input events that drive the application;

    • Begin Task 1.1.2

    • 1.1.2.1 TR: Review written description of need14

    • 1.1.2.2 Derive a list of customer visible outputs/inputs

    • 1.1.2.3 TR: Review outputs/inputs with customer and revise as required;

    • endtask Task 1.1.2

  • 1.1.3 定义每个主要功能的功能/行为;

    • 开始任务 1.1.3

    • 1.1.3.1 TR:审查任务 1.1.2 中导出的输出和输入数据对象;

    • 1.1.3.2 推导功能/行为模型;

    • 1.1.3.3 TR:与客户一起审查功能/行为并根据要求进行修改;

    • 结束任务 任务 1.1.3

  • 1.1.3 Define the functionality/behavior for each major function;

    • Begin Task 1.1.3

    • 1.1.3.1 TR: Review output and input data objects derived in task 1.1.2;

    • 1.1.3.2 Derive a model of functions/behaviors;

    • 1.1.3.3 TR: Review functions/behaviors with customer and revise as required;

    • endtask Task 1.1.3

  • 1.1.4 隔离要在软件中实现的技术元素;

  • 1.1.4 Isolate those elements of the technology to be implemented in software;

  • 1.1.5 研究现有软件的可用性;

  • 1.1.5 Research availability of existing software;

  • 1.1.6 定义技术可行性;

  • 1.1.6 Define technical feasibility;

  • 1.1.7 快速估算尺寸;

  • 1.1.7 Make quick estimate of size;

  • 1.1.8 创建范围定义;

  • 1.1.8 Create a Scope Definition;

  • 最终任务定义:任务 1.1

  • endtask definition: Task 1.1

流程设计语言细化中指出的任务和子任务构成了概念范围界定活动的详细时间表的基础。

The tasks and subtasks noted in the process design language refinement form the basis for a detailed schedule for the concept scoping activity.

25.9 定义任务网络

25.9 Defining a Task Network

各个任务和子任务根据其顺序具有相互依赖性。此外,当一个软件工程项目涉及多个人时,开发活动和任务很可能会并行执行。发生这种情况时,必须协调并发任务,以便在后续任务需要其工作产品时这些任务能够完成。

Individual tasks and subtasks have interdependencies based on their sequence. In addition, when more than one person is involved in a software engineering project, it is likely that development activities and tasks will be performed in parallel. When this occurs, concurrent tasks must be coordinated so that they will be complete when later tasks require their work product(s).

任务网络,也称为活动网络,是项目任务流的图形表示。任务网络是描述任务间依赖性和确定关键路径的有用机制。有时,它被用作将任务序列和依赖关系输入到自动化项目调度工具的机制。任务网络以其最简单的形式(在创建宏观计划时使用)描述了主要的软件工程任务。图 25.5显示了概念开发项目的示意性任务网络。第526页

A task network, also called an activity network, is a graphic representation of the task flow for a project. The task network is a useful mechanism for depicting intertask dependencies and determining the critical path. It is sometimes used as the mechanism through which task sequence and dependencies are input to an automated project scheduling tool. In its simplest form (used when creating a macroscopic schedule), the task network depicts major software engineering tasks. Figure 25.5 shows a schematic task network for a concept development project.Page 526

25.5概念开发 的任务网络

Figure 25.5 A task network for concept development

软件工程活动的并发性质导致了许多重要的调度要求。由于并行任务是异步发生的,因此您应该确定任务间依赖关系以确保持续完成任务。此外,您应该了解关键路径上的那些任务。也就是说,如果整个项目要按期完成,就必须按期完成任务。本章稍后将更详细地讨论这些问题。

The concurrent nature of software engineering activities leads to a number of important scheduling requirements. Because parallel tasks occur asynchronously, you should determine intertask dependencies to ensure continuous progress toward completion. In addition, you should be aware of those tasks that lie on the critical path. That is, tasks that must be completed on schedule if the project as a whole is to be completed on schedule. These issues are discussed in more detail later in this chapter.

需要注意的是,图 25.5所示的任务网络是宏观的。在详细的任务网络(详细时间表的前身)中,图中显示的每个活动都将被扩展。例如,任务 1.1 将扩展为显示第 25.8.2 节中显示的任务 1.1 细化中详细说明的所有任务。

It is important to note that the task network shown in Figure 25.5 is macroscopic. In a detailed task network (a precursor to a detailed schedule), each activity shown in the figure would be expanded. For example, Task 1.1 would be expanded to show all tasks detailed in the refinement of Tasks 1.1 shown in Section 25.8.2.

25.10 调度

25.10 Scheduling

软件项目的调度与任何多任务工程工作的调度没有太大区别。因此,通用的项目调度工具和技术无需修改即可应用于软件项目[Fer14]。任务之间的相互依赖性可以使用任务网络来定义。任务有时称为项目工作分解结构(WBS),是为整个产品或单个功能定义的。

Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort. Therefore, generalized project scheduling tools and techniques can be applied with little modification for software projects [Fer14]. Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions.

项目调度工具允许您 (1) 确定关键路径——决定项目持续时间的任务链,(2) 通过应用统计模型为各个任务建立“最有可能”的时间估计,以及 (3) 计算“边界时间”,定义特定任务的时间“窗口”[Ker17]。

Project scheduling tools allow you to (1) determine the critical path—the chain of tasks that determines the duration of the project, (2) establish “most likely” time estimates for individual tasks by applying statistical models, and (3) calculate “boundary times” that define a time “window” for a particular task [Ker17].

25.10.1 时间线图

25.10.1 Time-Line Charts

创建软件项目计划时,您从一组任务(工作分解结构)开始。如果使用自动化工具,工作分解将作为任务网络或任务大纲输入。然后输入每个任务的工作量、持续时间和开始日期。此外,任务可以分配给特定的个人。第527页

When creating a software project schedule, you begin with a set of tasks (the work breakdown structure). If automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration, and start date are then input for each task. In addition, tasks may be assigned to specific individuals.Page 527

此输入的结果是生成时间线图(也称为甘特图) 。可以为整个项目制定时间表。或者,可以为每个项目功能或为项目中的每个人开发单独的图表 [Toc18]。

As a consequence of this input, a time-line chart, also called a Gantt chart, is generated. A time-line chart can be developed for the entire project. Alternatively, separate charts can be developed for each project function or for each individual working on the project [Toc18].

图 25.6说明了时间线图的格式。它描述了软件项目进度表的一部分,强调了文字处理 (WP) 软件产品的概念范围界定任务。所有项目任务(用于概念范围界定)均列在左栏中。水平条表示每个任务的持续时间。当日历上同时出现多个柱时,就意味着任务并发。钻石表示里程碑。

Figure 25.6 illustrates the format of a time-line chart. It depicts a part of a software project schedule that emphasizes the concept scoping task for a word-processing (WP) software product. All project tasks (for concept scoping) are listed in the left-hand column. The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task concurrency is implied. The diamonds indicate milestones.

图25.6 时间线图示例

Figure 25.6 An example time-line chart

输入生成时间线图所需的信息后,大多数软件项目调度工具都会生成项目表- 所有项目任务、计划和实际开始和结束日期以及各种相关的表格列表。信息(图25.7)。项目表与时间线图结合使用,使您能够跟踪进度。第 528 页

Once the information necessary for the generation of a time-line chart has been input, the majority of software project scheduling tools produce project tables—a tabular listing of all project tasks, their planned and actual start and end dates, and a variety of related information (Figure 25.7). Used in conjunction with the time-line chart, project tables enable you to track progress.Page 528

图25.7项目表示

Figure 25.7 An example project table

25.10.2 跟踪时间表

25.10.2 Tracking the Schedule

如果开发得当,项目进度表将成为一个路线图,定义项目进展过程中要跟踪和控制的任务和里程碑。跟踪可以通过多种不同的方式完成:

If it has been properly developed, the project schedule becomes a road map that defines the tasks and milestones to be tracked and controlled as the project proceeds. Tracking can be accomplished in a number of different ways:

  • 定期召开项目状态会议,每个团队成员在会上报告进度和问题。

  • Conducting periodic project status meetings in which each team member reports progress and problems.

  • 评估整个软件工程过程中进行的所有评审的结果。

  • Evaluating the results of all reviews conducted throughout the software engineering process.

  • 确定正式项目里程碑(图 25.7中所示的菱形)是否已在预定日期完成。

  • Determining whether formal project milestones (the diamonds shown in Figure 25.7) have been accomplished by the scheduled date.

  • 将资源表中列出的每个项目任务的实际开始日期与计划开始日期进行比较(图 25.8)。

  • Comparing the actual start date to the planned start date for each project task listed in the resource table (Figure 25.8).

  • 与从业者进行非正式会议,以获得他们对迄今为止的进展和即将出现的问题的主观评估。

  • Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.

  • 跟踪项目速度,这是查看开发团队清理用户故事积压工作的速度的一种方式(第 3.5 节)。

  • Tracking the project velocity, which is a way of seeing how quickly the development team is clearing the user story backlog (Section 3.5).

事实上,所有这些跟踪技术都是由经验丰富的项目经理使用的。

In reality, all these tracking techniques are used by experienced project managers.

软件项目经理利用控制权来管理项目资源、处理问题并指导项目人员。如果事情进展顺利(即项目按计划进行且在预算之内,审查表明正在取得真正的进展并且正在达到里程碑),则控制就很轻。但当问题发生时,您必须进行控制以尽快解决问题。诊断出问题后,可以将额外的资源集中在问题领域:可以重新部署人员或重新定义项目进度。

A software project manager employs control to administer project resources, cope with problems, and direct project staff. If things are going well (i.e., the project is on schedule and within budget, reviews indicate that real progress is being made and milestones are being reached), control is light. But when problems occur, you must exercise control to reconcile them as quickly as possible. After a problem has been diagnosed, additional resources may be focused on the problem area: staff may be redeployed or the project schedule can be redefined.

当面临严重的截止日期压力时,经验丰富的项目经理有时会使用称为时间盒的项目调度和控制技术[Jal04]。时间盒策略认识到完整的产品可能无法在预定义的截止日期前交付。

When faced with severe deadline pressure, experienced project managers sometimes use a project scheduling and control technique called time-boxing [Jal04]. The time-boxing strategy recognizes that the complete product may not be deliverable by the predefined deadline.

第529页然后,与每个增量相关的任务都会受到时间限制。这意味着每项任务的计划是通过从增量的交付日期向后推算来调整的。每个任务周围都有一个“盒子”。当某项任务达到其时间范围的边界(正负 10%)时,工作就会停止并开始下一个任务。

Page 529The tasks associated with each increment are then time-boxed. This means that the schedule for each task is adjusted by working backward from the delivery date for the increment. A “box” is put around each task. When a task hits the boundary of its time box (plus or minus 10 percent), work stops and the next task begins.

时间盒通常与敏捷增量流程模型(第 4 章)相关,并且为每个增量交付导出一个时间表。这些任务成为增量计划的一部分,并在增量开发计划中进行分配。它们可以输入到调度软件(例如,Microsoft Project)并用于跟踪和控制。

Time-boxing is often associated with agile incremental process models (Chapter 4), and a schedule is derived for each incremental delivery. These tasks become part of the increment schedule and are allocated over the increment development schedule. They can be input to scheduling software (e.g., Microsoft Project) and used for tracking and control.

对时间限制方法的最初反应往往是负面的:“如果工作没有完成,我们该如何继续?” 答案在于完成工作的方式。当遇到时间盒边界时,很可能 90% 的任务已经完成。15剩余的 10% 虽然很重要,但可以 (1) 推迟到下一个增量,或 (2) 如果需要的话稍后完成。项目不会“卡在”某项任务上,而是会朝着交付日期前进。

The initial reaction to the time-boxing approach is often negative: “If the work isn’t finished, how can we proceed?” The answer lies in the way work is accomplished. By the time the time-box boundary is encountered, it is likely that 90 percent of the task has been completed.15 The remaining 10 percent, although important, can (1) be delayed until the next increment or (2) be completed later if required. Rather than becoming “stuck” on a task, the project proceeds toward the delivery date.

第530页

Page 530

25.11 总结

25.11 Summary

软件项目规划者必须在项目开始之前估计三件事:需要多长时间、需要多少努力以及将涉及多少人。此外,规划者必须预测所需的资源(硬件和软件)以及涉及的风险。

A software project planner must estimate three things before a project begins: how long it will take, how much effort will be required, and how many people will be involved. In addition, the planner must predict the resources (hardware and software) that will be required and the risk involved.

范围声明帮助规划者使用一种或多种技术进行估计,这些技术分为两大类:分解和经验建模。分解技术需要描述主要软件功能,然后估计 (1) LOC 数量,(2) 信息域内选定的值,(3) 用例数量,(4) 人员数量实现每项功能所需的月数,或 (5) 每项软件工程活动所需的人月数。经验技术使用根据经验得出的工作量和时间表达式来预测这些项目数量。自动化工具可用于实现特定的经验模型。

The statement of scope helps the planner to develop estimates using one or more techniques that fall into two broad categories: decomposition and empirical modeling. Decomposition techniques require a delineation of major software functions, followed by estimates of either (1) the number of LOC, (2) selected values within the information domain, (3) the number of use cases, (4) the number of person-months required to implement each function, or (5) the number of person-months required for each software engineering activity. Empirical techniques use empirically derived expressions for effort and time to predict these project quantities. Automated tools can be used to implement a specific empirical model.

准确的项目估算通常至少使用刚才提到的三种技术中的两种。通过比较和协调使用不同技术得出的估计,规划者更有可能得出准确的估计。软件项目估算永远不可能是一门精确的科学,但良好的历史数据和系统技术的结合可以提高估算的准确性。

Accurate project estimates generally use at least two of the three techniques just noted. By comparing and reconciling estimates developed using different techniques, the planner is more likely to derive an accurate estimate. Software project estimation can never be an exact science, but a combination of good historical data and systematic techniques can improve estimation accuracy.

调度是计划活动的顶峰,是软件项目管理的主要组成部分。当与估计方法和风险分析相结合时,调度为项目经理建立了路线图。

Scheduling is the culmination of a planning activity that is a primary component of software project management. When combined with estimation methods and risk analysis, scheduling establishes a road map for the project manager.

调度从流程分解开始。项目的特征用于为要完成的工作调整适当的任务集。任务网络描述了每个工程任务、其对其他任务的依赖性以及预计的持续时间。任务网络用于计算关键路径、时间线图和各种项目信息。使用计划作为指导,您可以跟踪和控制软件流程中的每个步骤。

Scheduling begins with process decomposition. The characteristics of the project are used to adapt an appropriate task set for the work to be done. A task network depicts each engineering task, its dependency on other tasks, and its projected duration. The task network is used to compute the critical path, a time-line chart, and a variety of project information. Using the schedule as a guide, you can track and control each step in the software process.

问题与思考点

Problems and Points to Ponder

25.1。假设您是一家为家用机器人构建软件的公司的项目经理。您已签约为为房主修剪草坪的机器人构建软件。编写描述软件的范围声明。确保你的范围声明是有限的。如果您不熟悉机器人,请在开始写作之前做一些研究。另外,请说明您对所需硬件的假设。替代:用您感兴趣的另一个问题替换割草机器人。

25.1. Assume that you are the project manager for a company that builds software for household robots. You have been contracted to build the software for a robot that mows the lawn for a homeowner. Write a statement of scope that describes the software. Be sure your statement of scope is bounded. If you’re unfamiliar with robots, do a bit of research before you begin writing. Also, state your assumptions about the hardware that will be required. Alternate: Replace the lawn-mowing robot with another problem that is of interest to you.

25.2. 对问题 25.1中描述的机器人软件进行功能分解。估计 LOC 中每个函数的大小。假设您的组织每分钟生产 450 个 LOC,每人每月的负担劳动力率为 7,000 美元,请使用本章中描述的基于 LOC 的估算技术来估算构建软件所需的工作量和成本。

25.2. Do a functional decomposition of the robot software you described in Problem 25.1. Estimate the size of each function in LOC. Assuming that your organization produces 450 LOC/pm with a burdened labor rate of $7,000 per person-month, estimate the effort and cost required to build the software using the LOC-based estimation technique described in this chapter.

25.3。开发一个电子表格模型来实现本章中描述的一种或多种估计技术。或者,从基于网络的来源获取一个或多个在线模型以进行估计。

25.3. Develop a spreadsheet model that implements one or more of the estimation techniques described in this chapter. Alternatively, acquire one or more online models for estimation from Web-based sources.

第531页25.4。成本和进度估算是在软件项目规划期间(在进行详细的软件需求分析或设计之前)制定的,这似乎很奇怪。您认为为什么这样做?是否存在不应该这样做的情况?

Page 53125.4. It seems odd that cost and schedule estimates are developed during software project planning—before detailed software requirements analysis or design has been conducted. Why do you think this is done? Are there circumstances when it should not be done?

25.5。宏观时间表和详细时间表有什么区别?仅制定宏观进度表是否可以管理项目?为什么?

25.5. What is the difference between a macroscopic schedule and a detailed schedule? Is it possible to manage a project if only a macroscopic schedule is developed? Why?

25.6。人与时间之间的关系是高度非线性的。使用 Putnam 的软件方程(第 25.8.2 节中描述),开发一个表格,将人数与需要 50000 LOC 和 15 人年工作量的软件项目的项目持续时间联系起来(生产率参数为 5000,B = 0.37 。假设软件必须在 24 个月正负 12 个月内交付。

25.6. The relationship between people and time is highly nonlinear. Using Putnam’s software equation (described in Section 25.8.2), develop a table that relates number of people to project duration for a software project requiring 50000 LOC and 15 person-years of effort (the productivity parameter is 5000 and B = 0.37). Assume that the software must be delivered in 24 months plus or minus 12 months.

25.7。假设一所大学与您签订了开发在线课程注册系统(OLCRS)的合同。首先,充当客户(如果您是学生,那应该很容易)并指定一个好的系统的特征。(或者,您的讲师将为您提供系统的一组初步要求。)使用本章中讨论的估计方法,为 OLCRS 制定工作量和持续时间估计。建议您如何:

25.7. Assume that a university has contracted you to develop an online course registration system (OLCRS). First, act as the customer (if you’re a student, that should be easy) and specify the characteristics of a good system. (Alternatively, your instructor will provide you with a set of preliminary requirements for the system.) Using the estimation methods discussed in this chapter, develop an effort and duration estimate for OLCRS. Suggest how you would:

  1. 定义 OLCRS 项目期间的并行工作活动。

  2. Define parallel work activities during the OLCRS project.

  3. 在整个项目中分配精力。

  4. Distribute effort throughout the project.

  5. 为项目建立里程碑。

  6. Establish milestones for the project.

25.8。为 OLCRS 项目选择适当的任务集。

25.8. Select an appropriate task set for the OLCRS project.

25.9。为问题 25.8 中描述的 OLCRS 或您感兴趣的另一个软件项目定义一个任务网络。确保显示任务和里程碑,并为每项任务附加工作量和持续时间估计。如果可能,请使用自动调度工具来执行此工作。

25.9. Define a task network for OLCRS described in Problem 25.8, or alternatively, for another software project that interests you. Be sure to show tasks and milestones and to attach effort and duration estimates to each task. If possible, use an automated scheduling tool to perform this work.

25.10。使用日程安排工具(如果有)或纸笔(如果需要),为 OLCRS 项目制定时间表。

25.10. Using a scheduling tool (if available) or paper and pencil (if necessary), develop a time-line chart for the OLCRS project.

1如果您想知道,这个故事是自传体 (RSP)。

1 In case you were wondering, this story is autobiographical (RSP).

2第 26 章介绍了风险分析的系统技术。

2 Systematic techniques for risk analysis are presented in Chapter 26.

3由于问题需求发生变化时发生的“范围蔓延”,规模通常会增加。项目规模的增加会对项目成本和进度产生几何影响(Michael Mah,个人通讯)。

3 Size often increases due to “scope creep” that occurs when problem requirements change. Increases in project size can have a geometric impact on project cost and schedule (Michael Mah, personal communication).

4本书第二部分详细讨论了用例。用例是从用户的角度对用户与软件交互的基于场景的描述。

4 Use cases have been discussed in detail throughout Part Two of this book. A use case is a scenario-based description of the user’s interaction with the software from the user’s point of view.

5第 11 章简要考虑了 CBSE。

5 CBSE was considered briefly in Chapter 11.

6其他硬件(目标环境)是软件发布给最终用户后将在其上执行的计算机。

6 Other hardware—the target environment—is the computer on which the software will execute when it has been released to the end user.

7第 25.6.6 节建议使用用例作为自变量的经验模型。然而,迄今为止,在文献中出现的相对较少。

7 An empirical model using use cases as the independent variable is suggested in Section 25.6.6. However, relatively few have appeared in the literature to date.

8例如,COCOMO(构造成本模型)最初于 1981 年开发,随后发布了更新版本 COCOMO II 和 COCOMO III。有关 COCOMO 模型起源的演示文稿可以从以下网址下载:http://www.psmsc.com/UG2016/Presentations/p10-Clark-COCOMO%20III%20Presentation%20v1.pdf。

8 As an example, the COCOMO (Constructive Cost Model) was originally developed in 1981, with updated versions, COCOMO II and COCOMO III, released in later years. A presentation on the genesis of the COCOMO model can be downloaded from: http://www.psmsc.com/UG2016/Presentations/p10-Clark-COCOMO%20III%20Presentation%20v1.pdf.

9缩写词pm表示人月的努力。

9 The acronym pm means person-month of effort.

10估算值四舍五入至最接近的 1,000 美元和人月。鉴于估计精度的限制,进一步的精确度是不必要且不现实的。

10 Estimates are rounded to the nearest $1,000 and person-month. Further precision is unnecessary and unrealistic, given the limitations of estimation accuracy.

11为本项目选择的框架活动与第 2 章中讨论的一般活动有些不同。它们是客户沟通 (CC)、规划、风险分析、工程和构建/发布。

11 The framework activities chosen for this project differ somewhat from the generic activities discussed in Chapter 2. They are customer communication (CC), planning, risk analysis, engineering, and construction/release.

12事实上,由于不相关的会议、疾病、假期和各种其他原因,可用的工作量不到 3 个人日。然而,出于我们的目的,我们假设 100% 的可用性。

12 In reality, less than 3 person-days of effort are available because of unrelated meetings, sickness, vacation, and a variety of other reasons. For our purposes, however, we assume 100 percent availability.

13原始研究可在 [Nor70] 和 [Put78] 中找到。

13 Original research can be found in [Nor70] and [Put78].

14 TR 表示将进行技术审查(第 16 章)。

14 TR indicates that a technical review (Chapter 16) is to be conducted.

15愤世嫉俗的人可能还记得这样一句话:“系统的前 90% 需要 90% 的时间;剩下的 90% 需要花费 90% 的时间。” 系统剩下的 10% 需要 90% 的时间。”

15 A cynic might recall the saying: “The first 90 percent of the system takes 90 percent of the time; the remaining 10 percent of the system takes 90 percent of the time.”

第532页

Page 532

章节

chapter

26风险管理

26 Risk Management

Robert Charette [Cha89] 在他关于风险分析和管理的书中指出,“风险关系到未来发生的事情”。他正确地指出,关注今天和昨天不应该成为焦点,而应该提出关键问题:“。。。通过改变我们今天的行动,[我们能否]为明天的自己创造一个不同的、希望更好的情况的机会。” 这意味着“风险涉及选择”,这给我们的行动带来了不确定性。

In his book on risk analysis and management, Robert Charette [Cha89] notes that “risk concerns future happenings.” He correctly points out that concern about today and yesterday should not be the focus, but rather poses the pivotal question: “. . . by changing our actions today, [can we] create an opportunity for a different and hopefully better situation for ourselves tomorrow.” The implication is that “risk involves choice,” and that introduces uncertainty in our actions.

第533页当您考虑软件工程背景下的风险时,Charette 的概念基础总是显而易见的。未来是你所关心的——哪些风险可能会导致软件项目出错?您关心的是变化——客户需求、开发技术、目标环境以及与项目相关的所有其他实体的变化将如何影响及时性和整体成功?最后,你必须努力做出选择——你应该使用什么方法和工具,应该有多少人参与,对质量的重视程度是“足够的”?

Page 533When you consider risk in the context of software engineering, Charette’s conceptual underpinnings are always in evidence. The future is your concern—what risks might cause the software project to go awry? Change is your concern—how will changes in customer requirements, development technologies, target environments, and all other entities connected to the project affect timeliness and overall success? Last, you must grapple with choices—what methods and tools should you use, how many people should be involved, how much emphasis on quality is “enough”?

技术债务是一个术语,用于描述与推迟软件文档和重构等活动相关的成本。未偿还的技术债务可能会导致交付的软件产品功能不足、行为不稳定、质量差、文档不足以及不必要的复杂性。技术债务意味着,如果在项目开发过程中尽早而不是稍后处理问题,则可以减少处理技术问题的成本(精力、时间和资源)。与财务利息一样,技术债务随着时间的推移而增加,因为未识别的问题引入了早期复利。积累技术债务正在抵押项目的未来[Fai17]。

Technical debt is the term used to describe costs associated with putting off activities like software documentation and refactoring. Technical debt that is not paid can result in a delivered software product with inadequate functionality, erratic behavior, poor quality, insufficient documentation, and unnecessary complexity. Technical debt implies that the costs (effort, time, and resources) of dealing with technical issues can be reduced if problems are dealt with earlier rather than later during project development. Like financial interest, technical debt increases with time because unrecognized problems introduced early compound. Accumulating technical debt is mortgaging a project’s future [Fai17].

简单地转向敏捷软件开发并不能消除进行有意的风险管理的需要。Elbanna 和 Sarker [Elb16] 对几个广泛使用敏捷软件开发实践的组织进行了调查。他们发现敏捷项目中的一些开发风险似乎未得到管理。随着开发人员推动更多新代码,同时往往忘记花时间减少这种债务,技术债务可能会累积。此外,缺乏经验的敏捷团队往往会产生比遵循更受控制的开发模型可能产生的更多缺陷。敏捷团队可能更有可能使用非标准化的项目管理和测试工具。这些自治团队可能没有充分记录他们的决策过程。这可能会导致开发人员在未来的项目中重复过去的错误。只要软件开发人员意识到这些风险并制定计划在规定的冲刺期间对其进行管理,这些风险都不是无法控制的。

Simply moving to agile software development does not remove the need to do intentional risk management. Elbanna and Sarker [Elb16] conducted a survey of several organizations that made extensive use of agile software development practices. They found several development risks that seemed to go unmanaged in agile projects. Technical debt was likely to accumulate as developers pushed for more new code and at the same time often forgot to spend time reducing this debt. In addition, inexperienced agile teams tend to produce more defects than they might have following a more controlled development model. Agile teams may be more likely to use nonstandardized project management and testing tools. These autonomous teams may not be documenting their decision-making processes adequately. That can doom developers to repeat past errors on future projects. None of these risks is impossible to control, as long as software developers are aware of them and make plans to manage them during their time-boxed sprints.

26.1 被动与主动风险策略

26.1 Reactive Versus Proactive Risk Strategies

反应性风险策略被笑称为“印第安纳琼斯风险管理学派”[Tho92]。在以他名字命名的电影中,印第安纳·琼斯在遇到巨大困难时总是会说:“别担心,我会想办法的!” 印地从不担心问题,直到问题发生为止,他会以某种英勇的方式做出反应。

Reactive risk strategies have been laughingly called the “Indiana Jones school of risk management” [Tho92]. In the movies that carried his name, Indiana Jones, when faced with overwhelming difficulty, would invariably say, “Don’t worry, I’ll think of something!” Never worrying about problems until they happened, Indy would react in some heroic way.

可悲的是,一般的软件项目经理不是印第安纳琼斯,软件项目团队的成员也不是他值得信赖的伙伴。然而,大多数软件团队仍然仅仅依赖反应性风险策略。最好的情况是,反应性策略会监控项目可能存在的风险。如果它们成为实际问题,我们会留出资源来处理它们。更常见的是,软件团队在出现问题之前不会采取任何措施来应对风险。然后,团队立即采取行动,试图迅速纠正问题。这通常称为消防模式。当失败时,“危机管理”[Cha92] 就会接管,项目就处于真正的危险之中。

Sadly, the average software project manager is not Indiana Jones and the members of the software project team are not his trusty sidekicks. Yet, most software teams continue to rely solely on reactive risk strategies. At best, a reactive strategy monitors the project for likely risks. Resources are set aside to deal with them, should they become actual problems. More commonly, the software team does nothing about risks until something goes wrong. Then, the team flies into action trying to correct the problem rapidly. This is often called a fire-fighting mode. When this fails, “crisis management” [Cha92] takes over and the project is in real jeopardy.

第534页一个更加明智的风险管理策略是积极主动。主动风险策略早在技术工作开始之前就开始了。识别潜在风险,评估其概率和影响,并按重要性进行排名。然后,软件团队制定风险管理计划。主要目标是避免风险,但由于并非所有风险都可以避免,因此团队致力于制定应急计划,使其能够以受控且有效的方式做出响应。主动风险管理是可用于减少技术债务的软件工程工具之一。在本章的其余部分中,我们将讨论主动的风险管理策略。

Page 534A considerably more intelligent strategy for risk management is to be proactive. A proactive risk strategy begins long before technical work is initiated. Potential risks are identified, their probability and impact are assessed, and they are ranked by importance. Then, the software team establishes a plan for managing risk. The primary objective is to avoid risk, but because not all risks can be avoided, the team works to develop a contingency plan that will enable it to respond in a controlled and effective manner. Proactive risk management is one of the software engineering tools that can be used to reduce technical debt. Throughout the remainder of this chapter, we discuss a proactive strategy for risk management.

26.2 软件风险

26.2 Software Risks

尽管关于软件风险的正确定义存在相当多的争论,但人们普遍认为风险总是涉及两个特征:不确定性——风险可能发生也可能不发生;也就是说,不存在 100% 可能的风险1损失,如果风险成为现实,就会发生不良后果或损失 [Hig95]。分析风险时,量化与每种风险相关的不确定性水平和损失程度非常重要。为了实现这一目标,需要考虑不同类别的风险。

Although there has been considerable debate about the proper definition for software risk, there is general agreement that risk always involves two characteristics: uncertainty—the risk may or may not happen; that is, there are no 100 percent probable risks1—and loss—if the risk becomes a reality, unwanted consequences or losses will occur [Hig95]. When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated with each risk. To accomplish this, different categories of risks are considered.

项目风险威胁项目计划。也就是说,如果项目风险成为现实,项目进度很可能会推迟,成本也会增加。项目风险识别潜在的预算、进度、人员(人员和组织)、资源、利益相关者和需求问题及其对软件项目的影响。在第25章中,项目复杂性、规模和结构不确定性程度也被定义为项目(和估算)风险因素。

Project risks threaten the project plan. That is, if project risks become real, it is likely that the project schedule will slip and that costs will increase. Project risks identify potential budgetary, schedule, personnel (staffing and organization), resource, stakeholder, and requirements problems and their impact on a software project. In Chapter 25, project complexity, size, and the degree of structural uncertainty were also defined as project (and estimation) risk factors.

技术风险威胁着要生产的软件的质量和及时性。如果技术风险成为现实,实施可能会变得困难或不可能。技术风险识别潜在的设计、实施、接口、验证和维护问题。此外,规范模糊性、技术不确定性、技术过时和“前沿”技术也可能是风险因素。出现技术风险是因为问题比您想象的更难解决。

Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible. Technical risks identify potential design, implementation, interface, verification, and maintenance problems. In addition, specification ambiguity, technical uncertainty, technical obsolescence, and “leading-edge” technology can also be risk factors. Technical risks occur because the problem is harder to solve than you thought it would be.

业务风险威胁到要构建的软件的可行性,并且常常危及项目或产品。排名前五位的业务风险包括:(1) 构建了一个没人真正想要的优秀产品或系统(市场风险),(2) 构建了一个不再适合公司整体业务战略的产品(战略风险), (3) 开发出销售人员不明白如何销售的产品(销售风险),(4) 由于焦点变化或人员变动而失去高级管理层的支持(管理风险),以及 (5 ) 失去预算或人员承诺(预算风险)。

Business risks threaten the viability of the software to be built and often jeopardize the project or the product. Candidates for the top five business risks are (1) building an excellent product or system that no one really wants (market risk), (2) building a product that no longer fits into the overall business strategy for the company (strategic risk), (3) building a product that the sales force doesn’t understand how to sell (sales risk), (4) losing the support of senior management due to a change in focus or a change in people (management risk), and (5) losing budgetary or personnel commitment (budget risks).

值得注意的是,简单的风险分类并不总是有效。有些风险根本无法提前预测。

It is extremely important to note that simple risk categorization won’t always work. Some risks are simply unpredictable in advance.

第535页Charette [Cha89] 提出了另一种一般的风险分类。已知风险是在仔细评估项目计划、项目开发的业务和技术环境以及其他可靠信息源(例如,不切实际的交付日期、缺乏记录的需求或软件范围、质量不佳)后可以发现的风险。开发环境)。可预测的风险是根据过去的项目经验推断出来的(例如,员工流动、与客户沟通不畅、在满足持续维护请求时减少员工工作量)。不可预测的风险是甲板上的小丑。它们可能而且确实发生,但很难提前识别。

Page 535Another general categorization of risks has been proposed by Charette [Cha89]. Known risks are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date, lack of documented requirements or software scope, poor development environment). Predictable risks are extrapolated from past project experience (e.g., staff turnover, poor communication with the customer, dilution of staff effort as ongoing maintenance requests are serviced). Unpredictable risks are the joker in the deck. They can and do occur, but they are extremely difficult to identify in advance.

26.3 风险识别

26.3 Risk Identification

风险识别是明确项目计划(估算、进度、资源负载等)面临的威胁的系统性尝试。通过识别已知和可预测的风险,项目经理迈出了尽可能避免风险并在必要时控制风险的第一步。

Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary.

第 26.2 节中介绍的每个类别都有两种不同类型的风险。通用风险是每个软件项目的潜在威胁。只有那些对要构建的软件特定的技术、人员和环境有清晰了解的人才能识别特定于产品的风险。尽管一般风险很重要,但最令人头疼的是产品特定的风险。请务必投入时间来识别尽可能多的特定于产品的风险。要识别特定于产品的风险,您应该首先检查项目计划和软件范围声明,然后回答以下问题:“该产品的哪些特殊特性可能会威胁我们的项目计划?”第536页

There are two distinct types of risks for each of the categories that have been presented in Section 26.2. Generic risks are a potential threat to every software project. Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the software that is to be built. Although generic risks are important to consider, it’s the product-specific risks that cause the most headaches. Be certain to invest the time to identify as many product-specific risks as possible. To identify product-specific risks, you should begin by examining the project plan and the software statement of scope and then develop an answer to the question, “What special characteristics of this product may threaten our project plan?”Page 536

识别风险的一种方法是创建风险项目清单。该清单可用于风险识别,并重点关注以下通用子类别中已知和可预测风险的某些子集:

One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories:

  • 产品尺寸。与要构建或修改的软件的总体规模相关的风险。

  • Product size. Risks associated with the overall size of the software to be built or modified.

  • 商业冲击。与管理层或市场施加的限制相关的风险。

  • Business impact. Risks associated with constraints imposed by management or the marketplace.

  • 利益相关者特征。与利益相关者的复杂程度以及开发人员及时与利益相关者沟通的能力相关的风险。

  • Stakeholder characteristics. Risks associated with the sophistication of the stakeholders and the developer’s ability to communicate with stakeholders in a timely manner.

  • 流程定义。与软件过程的定义程度和开发组织遵循的程度相关的风险。

  • Process definition. Risks associated with the degree to which the software process has been defined and is followed by the development organization.

  • 开发环境。与用于构建产品的工具的可用性和质量相关的风险。

  • Development environment. Risks associated with the availability and quality of the tools to be used to build the product.

  • 技术待建。与要构建的系统的复杂性以及系统所封装的技术的“新颖性”相关的风险。

  • Technology to be built. Risks associated with the complexity of the system to be built and the “newness” of the technology that is packaged by the system.

  • 员工规模和经验。与执行该工作的软件工程师的整体技术和项目经验相关的风险。

  • Staff size and experience. Risks associated with the overall technical and project experience of the software engineers who will do the work.

风险项目清单可以以不同的方式组织。可以为每个软件项目回答与每个主题相关的问题。这些问题的答案使您能够估计风险的影响。不同的风险项目清单格式只是列出与每个通用子类别相关的特征。最后,列出了一组“风险成分和驱动因素”[AFC88]及其发生概率。性能、支持、成本和进度的驱动因素将在回答后面的问题时讨论。

The risk item checklist can be organized in different ways. Questions relevant to each of the topics can be answered for each software project. The answers to these questions allow you to estimate the impact of risk. A different risk item checklist format simply lists characteristics that are relevant to each generic subcategory. Finally, a set of “risk components and drivers” [AFC88] are listed along with their probability of occurrence. Drivers for performance, support, cost, and schedule are discussed in answer to later questions.

网上有几个软件项目风险的综合清单(例如,[Arn11]、[NAS07])。您可以使用这些清单来深入了解软件项目的一般风险。除了使用检查表之外,还提出了风险模式([Mil04]、[San17])作为风险识别的系统方法。

Several comprehensive checklists for software project risk are available on the Web (e.g., [Arn11], [NAS07]). You can use these checklists to gain insight into generic risks for software projects. In addition to the use of checklists, risk patterns ([Mil04], [San17]) have been proposed as a systematic approach to risk identification.

26.3.1 评估总体项目风险

26.3.1 Assessing Overall Project Risk

那么我们如何确定我们正在开发的软件项目是否面临严重风险呢?以下问题是根据对世界不同地区经验丰富的软件项目经理进行调查获得的风险数据得出的[Kei98]。这些问题按照其对项目成功的相对重要性排序。

So how can we determine if the software project we’re working on is at serious risk? The following questions have been derived from risk data obtained by surveying experienced software project managers in different parts of the world [Kei98]. The questions are ordered by their relative importance to the success of a project.

  1. 顶级软件和客户经理是否正式承诺支持该项目?

  2. Have top software and customer managers formally committed to support the project?

  3. 第537页最终用户是否热情地致力于该项目和要构建的系统/产品?

  4. Page 537Are end users enthusiastically committed to the project and the system/product to be built?

  5. 软件工程团队及其客户是否完全理解需求?

  6. Are requirements fully understood by the software engineering team and its customers?

  7. 客户是否充分参与了需求的定义?

  8. Have customers been involved fully in the definition of requirements?

  9. 最终用户是否有现实的期望?

  10. Do end users have realistic expectations?

  11. 项目范围稳定吗?

  12. Is the project scope stable?

  13. 软件工程团队是否拥有合适的技能组合?

  14. Does the software engineering team have the right mix of skills?

  15. 项目需求稳定吗?

  16. Are project requirements stable?

  17. 项目团队是否有要实施的技术的经验?

  18. Does the project team have experience with the technology to be implemented?

  19. 项目团队的人数是否足以完成这项工作?

  20. Is the number of people on the project team adequate to do the job?

  21. 所有客户/用户群体是否都同意项目的重要性以及要构建的系统/产品的要求?

  22. Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built?

如果其中任何一个问题的答案是否定的,则应立即采取缓解、监控和管理措施。项目面临风险的程度与对这些问题的负面回答的数量成正比。

If any one of these questions is answered negatively, mitigation, monitoring, and management steps should be instituted without fail. The degree to which the project is at risk is directly proportional to the number of negative responses to these questions.

26.3.2 风险成分和驱动因素

26.3.2 Risk Components and Drivers

美国空军 [AFC88] 出版了一本小册子,其中包含有关软件风险识别和消除的优秀指南。空军方法要求项目经理识别影响软件风险组件(性能、成本、支持和进度)的风险驱动因素。在本次讨论中,风险成分的定义如下:

The U.S. Air Force [AFC88] has published a pamphlet that contains excellent guidelines for software risk identification and abatement. The Air Force approach requires that the project manager identify the risk drivers that affect software risk components—performance, cost, support, and schedule. In the context of this discussion, the risk components are defined in the following manner:

  • 绩效风险。产品满足其要求并适合其预期用途的不确定性程度。

  • Performance risk. The degree of uncertainty that the product will meet its requirements and be fit for its intended use.

  • 成本风险。维持项目预算的不确定性程度。

  • Cost risk. The degree of uncertainty that the project budget will be maintained.

  • 支持风险。最终软件易于纠正、适应和增强的不确定性程度。

  • Support risk. The degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.

  • 安排风险。项目进度得以维持以及产品按时交付的不确定性程度。

  • Schedule risk. The degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.

每个风险驱动因素对风险组成部分的影响分为四个影响类别之一:可忽略、边际、严重或灾难性。Boehm [Boe89] 认为可以忽略不计的影响只会带来不便。减轻影响所需的额外成本非常低。边际影响可能会影响次要任务目标或要求,但不会影响整体任务的成功。成本会高一些,但在可控范围内。关键影响将直接影响系统性能和部分或全部要求,并使任务成功受到质疑。缓解成本会很高。最后,灾难性的影响将导致任务失败。缓解措施的成本将是不可接受的。

The impact of each risk driver on the risk component is divided into one of four impact categories—negligible, marginal, critical, or catastrophic. Boehm [Boe89] suggests that negligible impact results only in inconvenience. The additional cost required to mitigate the impact is very low. Marginal impact might affect secondary mission objectives or requirements but would not impact overall mission success. Cost would be somewhat higher but manageable. Critical impact would directly affect system performance and some or all requirements and would bring mission success into question. Cost to mitigate would be high. Finally, catastrophic impact would result in mission failure. The cost of mitigation would be unacceptable.

第538页

Page 538

26.4 风险预测

26.4 Risk Projection

风险预测,也称为风险估计,试图​​以两种方式对每种风险进行评级:(1) 风险真实存在并将发生的可能性或概率,(2) 如果发生,与风险相关的问题的后果。您与其他经理和技术人员一起执行四个风险预测步骤:

Risk projection, also called risk estimation, attempts to rate each risk in two ways—(1) the likelihood or probability that the risk is real and will occur and (2) the consequences of the problems associated with the risk, should it occur. You work along with other managers and technical staff to perform four risk projection steps:

  1. 建立反映风险感知可能性的量表。

  2. Establish a scale that reflects the perceived likelihood of a risk.

  3. 描述风险的后果。

  4. Delineate the consequences of the risk.

  5. 估计风险对项目和产品的影响。

  6. Estimate the impact of the risk on the project and the product.

  7. 评估风险预测的整体准确性,以免出现误解。

  8. Assess the overall accuracy of the risk projection so that there will be no misunderstandings.

这些步骤的目的是通过确定优先级的方式考虑风险。没有哪个软件团队有足够的资源以同样严格的程度解决所有可能的风险。通过确定风险的优先级,您可以将资源分配到影响最大的地方。

The intent of these steps is to consider risks in a manner that leads to prioritization. No software team has the resources to address every possible risk with the same degree of rigor. By prioritizing risks, you can allocate resources where they will have the most impact.

26.4.1 制定风险表

26.4.1 Developing a Risk Table

风险表为您提供了一种简单的风险预测技术。2风险表样本如图 26.1所示。

A risk table provides you with a simple technique for risk projection.2 A sample risk table is illustrated in Figure 26.1.

图26.1 排序前的风险表样本

Figure 26.1 Sample risk table prior to sorting

影响值:

Impact values:

  1. - 灾难性的
  2. - catastrophic
  3. - 批判的
  4. - critical
  5. - 边缘
  6. - marginal
  7. - 可以忽略不计
  8. - negligible

首先,您在表的第一列中列出所有风险(无论风险有多小)。这可以借助第 26.3 节中引用的风险项目清单来完成。每个风险在第二列中进行分类(例如,PS 表示项目规模风险,BU 表示业务风险)。每个风险发生的概率输入到表的下一列中。每个风险的概率值可以由团队成员单独估计。实现这一目标的一种方法是以循环方式对各个团队成员进行民意调查,直到他们对风险概率的集体评估开始收敛。第539页

You begin by listing all risks (no matter how remote) in the first column of the table. This can be accomplished with the help of the risk item checklists referenced in Section 26.3. Each risk is categorized in the second column (e.g., PS implies a project size risk, BU implies a business risk). The probability of occurrence of each risk is entered in the next column of the table. The probability value for each risk can be estimated by team members individually. One way to accomplish this is to poll individual team members in round-robin fashion until their collective assessment of risk probability begins to converge.Page 539

另一个可能的起点是查看先前项目的风险评估表,看看哪些风险适用于当前项目,哪些不适用,并确定应添加的风险。风险评估并不总是需要从头开始重新创建。敏捷开发人员经常从事类似的项目,并且可以通过维护全公司共享的风险管理程序列表来实现成本节约。

Another possible starting point would be to look at the risk assessment table for a previous project and see which risks apply to your current project, which do not, and identify risks that should be added. Risk assessment does not always need to be re-created from scratch. Agile developers often work on similar projects and can realize the cost savings by maintaining lists of risk management procedures shared companywide.

接下来,评估每个风险的影响。使用图 26.1中所示的特征来评估每个风险成分,并确定影响类别。四个风险组成部分(性能、支持、成本和进度)中每一个的类别均取3 的平均值,以确定总体影响值。

Next, the impact of each risk is assessed. Each risk component is assessed using the characterization presented in Figure 26.1, and an impact category is determined. The categories for each of the four risk components—performance, support, cost, and schedule—are averaged3 to determine an overall impact value.

完成风险表的前四列后,该表将按概率和影响进行排序。高概率、高影响的风险渗透到表格的顶部,而低概率的风险则下降到底部。这实现了一阶风险优先级排序。

Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact. High-probability, high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom. This accomplishes first-order risk prioritization.

然后,项目经理可以在表中的某行建立一条截止线(图 26.1)。所有高于截止线的风险都应该得到管理。标记为 RMMM 的列包含指向风险缓解、监控和管理计划的指针,或者为高于截止值的所有风险开发的风险信息表的集合。RMMM 计划和风险信息表在第 26.526.6节中讨论。

A project manager can then establish a cutoff line at some row in the table (Figure 26.1). All risks that lie above the cutoff line should be managed. The column labeled RMMM contains a pointer into a risk mitigation, monitoring, and management plan or, alternatively, a collection of risk information sheets developed for all risks that lie above the cutoff. The RMMM plan and risk information sheets are discussed in Sections 26.5 and 26.6.

可以通过进行单独估计然后制定单一共识值来确定风险概率。尽管这种方法是可行的,但已经开发了用于确定风险概率的更复杂的技术(例如,[McC09])。最近的工作利用模糊逻辑4来确定容易失败的软件项目的特征。这些项目通常具有多个相互关联的风险因素,这些因素受到不精确或不确定性的影响,需要使用专家知识和模糊逻辑来更好地理解其综合风险影响的性质[Rod16]。

Risk probability can be determined by making individual estimates and then developing a single consensus value. Although this approach is workable, more sophisticated techniques for determining risk probability have been developed (e.g., [McC09]). Recent work makes use of fuzzy logic4 to determine the characteristics that make software projects that are prone to failure. These projects often have multiple interrelated risk factors that are affected by imprecision or uncertainty and require use of expert knowledge and fuzzy logic to better understand the nature of their combined risk impact [Rod16].

参见图26.2,风险影响和概率对管理层关注度有明显影响。被归类为高影响但发生概率极低的风险因素不应占用大量管理时间。然而,中度至高概率的高影响风险和高概率的低影响风险应转入后续的风险分析步骤。第 540 页

Referring to Figure 26.2, risk impact and probability have a distinct influence on management concern. A risk factor that is classified as high impact but has a very low probability of occurrence should not absorb a significant amount of management time. However, high-impact risks with moderate to high probability and low-impact risks with high probability should be carried forward into the risk analysis steps that follow.Page 540

26.2风险 和管理问题

Figure 26.2 Risk and management concern

26.4.2 评估风险影响

26.4.2 Assessing Risk Impact

风险发生时可能产生的后果受三个因素影响:风险的性质、范围和时间。风险的性质表明风险发生时可能出现的问题。例如,客户硬件的外部接口定义不明确(技术风险)将妨碍早期设计和测试,并可能导致项目后期出现系统集成问题。风险的范围结合了严重性(到底有多严重?)及其总体分布(项目的多少部分将受到影响或有多少利益相关者受到伤害?)。最后,风险发生的时间考虑了影响何时以及持续多久。在大多数情况下,您希望“坏消息”尽快发生,但在某些情况下,延迟的时间越长越好。

Three factors affect the consequences that are likely if a risk does occur: its nature, its scope, and its timing. The nature of the risk indicates the problems that are likely if it occurs. For example, a poorly defined external interface to customer hardware (a technical risk) will preclude early design and testing and will likely lead to system integration problems late in a project. The scope of a risk combines the severity (just how serious is it?) with its overall distribution (how much of the project will be affected or how many stakeholders are harmed?). Finally, the timing of a risk considers when and for how long the impact will be felt. In most cases, you want the “bad news” to occur as soon as possible, but in some cases, the longer the delay, the better.

再次回到美国空军提出的风险分析方法[AFC88],您可以应用以下步骤来确定风险的总体后果: (1) 确定每个风险成分的平均发生概率值;(2) 使用第 26.3.2 节中提出的讨论,根据所示标准确定每个组件的影响,以及 (3) 完成风险表并按照前面各节中所述分析结果。

Returning once more to the risk analysis approach proposed by the U.S. Air Force [AFC88], you can apply the following steps to determine the overall consequences of a risk: (1) determine the average probability of occurrence value for each risk component; (2) using the discussion presented in Section 26.3.2, determine the impact for each component based on the criteria shown, and (3) complete the risk table and analyze the results as described in the preceding sections.

总体风险暴露(RE) 使用以下关系确定 [Hal98]:

The overall risk exposure (RE), is determined using the following relationship [Hal98]:

RE= P × C

RE = P × C

其中P是风险发生的概率,C是风险发生时项目的成本。第541页

where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur.Page 541

例如,假设软件团队按以下方式定义项目风险:

For example, assume that the software team defines a project risk in the following manner:

  • 风险识别。实际上,计划重用的软件组件中只有 70% 会集成到应用程序中。其余功能必须定制开发。

  • Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be custom developed.

  • 风险概率。百分之八十(有可能)。

  • Risk probability. Eighty percent (likely).

  • 风险影响。计划了 60 个可重复使用的软件组件。如果只能使用 70%,则必须从头开始开发 18 个组件(除了已计划开发的其他定制软件)。由于平均组件为 100 个 LOC,并且本地数据表明每个 LOC 的软件工程成本为 14.00 美元,因此开发组件的总成本(影响)将为 18 × 100 × 14 = 25,200 美元。

  • Risk impact. Sixty reusable software components were planned. If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Because the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 × 100 × 14 = $25,200.

  • 风险暴露。RE = 0.80 × 25,200 ~ 20,200 美元。

  • Risk exposure. RE = 0.80 × 25,200 ~ $20,200.

一旦对风险成本进行了估计,就可以计算风险表中每个风险的风险暴露。所有风险的总风险暴露(高于风险表中的截止值)可以提供调整项目最终成本估算的方法。它还可用于预测项目进度期间不同时间点所需的人力资源的可能增加。

Risk exposure can be computed for each risk in the risk table, once an estimate of the cost of the risk is made. The total risk exposure for all risks (above the cutoff in the risk table) can provide a means for adjusting the final cost estimate for a project. It can also be used to predict the probable increase in staff resources required at various points during the project schedule.

随着软件项目的进行,第 26.4.1 节第 26.4.2节中描述的风险预测和分析技术将被迭代应用。5项目团队应定期重新访问风险表,重新评估每个风险,以确定新情况何时导致其概率和影响发生变化。完成此活动后,团队可能决定向表中添加新风险,删除一些不再相关的风险,或更改其他风险的相对位置。团队应将所有风险的 RE 与其项目成本估算进行比较。如果总 RE 大于项目成本的 50%,则项目的可行性必须受到质疑。

The risk projection and analysis techniques described in Sections 26.4.1 and 26.4.2 are applied iteratively as the software project proceeds.5 The project team should revisit the risk table at regular intervals, reevaluating each risk to determine when new circumstances cause its probability and impact to change. After completing this activity, the team may decide to add new risks to the table, remove some risks that are no longer relevant, or change the relative positions of still others. The team should compare the RE for all risks to their project cost estimate. If the total RE is greater than 50 percent of the project cost, the viability of the project must be questioned.

26.5 风险细化

26.5 Risk Refinement

在项目规划的早期阶段,可能会非常笼统地陈述风险。随着时间的推移,对项目和风险的了解越来越多,有可能将风险细化为一组更详细的风险,每个风险都更容易减轻、监控和管理。

During early stages of project planning, a risk may be stated quite generally. As time passes and more is learned about the project and the risk, it may be possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and manage.

实现此目的的一种方法是以条件-转换-结果(CTC) 格式表示风险[Glu94]。即风险以如下形式表述:

One way to do this is to represent the risk in condition-transition-consequence (CTC) format [Glu94]. That is, the risk is stated in the following form:

给定<条件>,那么就需要担心(可能)<结果>。

Given that <condition> then there is concern that (possibly) <consequence>.

使用第 26.4.2 节中提到的重用风险的 CTC 格式,您可以编写:

Using the CTC format for the reuse risk noted in Section 26.4.2, you could write:

鉴于所有可重用软件组件必须符合特定的设计标准,而有些则不符合,那么人们担心(可能)只有 70% 的计划可重用模块可以集成到竣工系统中,从而需要定制设计剩余 30% 的组件。

Given that all reusable software components must conform to specific design standards and that some do not conform, then there is concern that (possibly) only 70 percent of the planned reusable modules may be integrated into the as-built system, resulting in the need to custom engineer the remaining 30 percent of components.

这个一般条件可以通过以下方式细化:

This general condition can be refined in the following manner:

  • 子条件 1.某些可重复使用的组件是由不了解内部设计标准的第三方开发的。

  • Subcondition 1. Certain reusable components were developed by a third party with no knowledge of internal design standards.

  • 子条件2、组件接口的设计标准尚未固化,可能不符合某些现有的可复用组件。

  • Subcondition 2. The design standard for component interfaces has not been solidified and may not conform to certain existing reusable components.

  • 第543页子条件 3.某些可重用组件是用目标环境不支持的语言实现的。

  • Page 543Subcondition 3. Certain reusable components have been implemented in a language that is not supported on the target environment.

与这些细化子条件相关的后果保持不变(即,30% 的软件组件必须进行定制设计),但细化有助于隔离潜在风险,并可能导致更轻松的分析和响应。

The consequences associated with these refined subconditions remain the same (i.e., 30 percent of software components must be custom engineered), but the refinement helps to isolate the underlying risks and might lead to easier analysis and response.

26.6 风险缓解、监控和管理

26.6 Risk Mitigation, Monitoring, and Management

到目前为止提出的所有风险分析活动都有一个目标——协助项目团队制定应对风险的策略。有效的策略必须考虑三个问题:风险规避、风险监控、风险管理和应急计划。

All the risk analysis activities presented to this point have a single goal—to assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues: risk avoidance, risk monitoring, and risk management and contingency planning.

如果软件团队对风险采取积极主动的方法,那么避免总是最好的策略。这是通过制定风险缓解计划来实现的例如,假设高员工流动率被记为项目风险r 1。根据其历史和管理直觉,高流动率的可能性l 1估计为 0.70(70%,相当高),并且影响x 1预计为关键。也就是说,高流动率将对项目成本和进度产生重大影响。

If a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation. For example, assume that high staff turnover is noted as a project risk r1. Based on its history and management intuition, the likelihood l1 of high turnover is estimated to be 0.70 (70 percent, rather high) and the impact x1 is projected as critical. That is, high turnover will have a critical impact on project cost and schedule.

为了降低这种风险,您需要制定减少营业额的策略。可能采取的步骤包括:

To mitigate this risk, you would develop a strategy for reducing turnover. Among the possible steps to be taken are:

  • 与现有员工会面,以确定离职原因(例如,工作条件差、工资低、就业市场竞争激烈)。

  • Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, competitive job market).

  • 在项目开始之前缓解那些在您控制范围内的原因。

  • Mitigate those causes that are under your control before the project starts.

  • 项目开始后,假设会发生人员流动,并开发技术以确保人员离开时的连续性。

  • Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave.

  • 组织项目团队,以便广泛分散有关每个开发活动的信息。

  • Organize project teams so that information about each development activity is widely dispersed.

  • 定义工作产品标准并建立机制,以确保及时开发所有模型和文档。

  • Define work product standards and establish mechanisms to be sure that all models and documents are developed in a timely manner.

  • 对所有工作进行同行评审(以便不止一个人“跟上进度”)。

  • Conduct peer reviews of all work (so that more than one person is “up to speed”).

  • 为每位关键技术人员分配一名后备人员。

  • Assign a backup staff member for every critical technologist.

随着项目的进展,风险监控活动开始。项目经理监控可以指示风险是否变得更大或更不可能的因素。在人员流动率较高的情况下,基于项目压力的团队成员的总体态度、团队的凝聚程度、团队成员之间的人际关系、薪酬和福利的潜在问题以及公司内的工作机会和机会外面都是被监控的。

As the project proceeds, risk-monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming more likely or less likely. In the case of high staff turnover, the general attitude of team members based on project pressures, the degree to which the team has jelled, interpersonal relationships among team members, potential problems with compensation and benefits, and the availability of jobs within the company and outside it are all monitored.

除了监控这些因素之外,项目经理还应该监控风险缓解步骤的有效性。例如,此处提到的风险缓解步骤要求定义工作产品标准和机制,以确保及时开发工作产品。如果关键人员离开项目,这是确保连续性的一种机制。项目经理应该仔细监控工作产品,以确保每个工作产品都可以独立存在,并且如果新人被迫在项目中间的某个地方加入软件团队,每个产品都会传递必要的信息。第 544 页

In addition to monitoring these factors, a project manager should monitor the effectiveness of risk mitigation steps. For example, a risk mitigation step noted here called for the definition of work product standards and mechanisms to be sure that work products are developed in a timely manner. This is one mechanism for ensuring continuity, should a critical individual leave the project. The project manager should monitor work products carefully to ensure that each can stand on its own and that each imparts information that would be necessary if a newcomer were forced to join the software team somewhere in the middle of the project.Page 544

风险管理和应急计划假设缓解措施失败并且风险已成为现实。继续这个例子,该项目正在顺利进行,一些人宣布他们将离开。如果遵循了缓解策略,则可以进行备份,记录信息,并且知识已分散在整个团队中。此外,您可以暂时将资源(并重新调整项目进度)重新集中到人员配备齐全的职能部门,从而使必须添加到团队中的新人能够“跟上进度”。那些离开的人被要求停止所有工作,并在“知识转移模式”中度过最后几周。这可能包括基于视频的知识捕获、“评论文档或维基”的开发,和/或与将继续参与该项目的其他团队成员会面。

Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. Continuing the example, the project is well under way and several people announce that they will be leaving. If the mitigation strategy has been followed, backup is available, information is documented, and knowledge has been dispersed across the team. In addition, you can temporarily refocus resources (and readjust the project schedule) to those functions that are fully staffed, enabling newcomers who must be added to the team to “get up to speed.” Those individuals who are leaving are asked to stop all work and spend their last weeks in “knowledge transfer mode.” This might include video-based knowledge capture, the development of “commentary documents or Wikis,” and/or meeting with other team members who will remain on the project.

值得注意的是,风险缓解、监控和管理 (RMMM) 步骤会产生额外的项目成本。例如,花时间备份每项关键技术都需要花钱。因此,风险管理的一部分是评估 RMMM 步骤所产生的收益何时超过与实施这些步骤相关的成本。您需要执行经典的成本效益分析。如果特定风险的 RE 小于风险缓解的成本,则不要尝试缓解风险,而是继续监控风险。如果高周转率的风险规避措施将使项目成本和工期增加约 15%,但主要成本因素是“备用”,则管理层可能会决定不实施此步骤。另一方面,如果风险规避措施预计会使成本增加 5%,而持续时间仅增加 3%,那么管理层可能会将所有措施落实到位。

It is important to note that risk mitigation, monitoring, and management (RMMM) steps incur additional project cost. For example, spending the time to back up every critical technology costs money. Part of risk management, therefore, is to evaluate when the benefits accrued by the RMMM steps are outweighed by the costs associated with implementing them. You need to perform a classic cost-benefit analysis. If RE for a specific risk is less than the cost of risk mitigation, don’t try to mitigate the risk but continue to monitor it. If risk aversion steps for high turnover will increase both project cost and duration by an estimated 15 percent, but the predominant cost factor is “backup,” management may decide not to implement this step. On the other hand, if the risk aversion steps are projected to increase costs by 5 percent and duration by only 3 percent, management will likely put all into place.

对于大型项目,可能会识别出 30 或 40 个风险。如果为每个步骤确定三到七个风险管理步骤,则风险管理可能需要大量资源来管理。因此,您应该根据软件风险调整 Pareto 80-20 规则。经验表明,80% 的总体项目风险(即 80% 的项目失败可能性)只能由 20% 的已识别风险来解释。早期风险分析步骤中执行的工作将帮助您确定那 20% 中存在哪些风险(例如,导致最高风险暴露的风险)。因此,某些已识别、评估和预测的风险可能不会纳入 RMMM 计划中——它们不会落入关键的 20%(具有最高项目优先级的风险)。

For a large project, 30 or 40 risks may be identified. If between three and seven risk management steps are identified for each, risk management may require significant resources to manage. For this reason, you should adapt the Pareto 80–20 rule to software risk. Experience indicates that 80 percent of the overall project risk (i.e., 80 percent of the potential for project failure) can be accounted for by only 20 percent of the identified risks. The work performed during earlier risk analysis steps will help you to determine which of the risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure). For this reason, some of the risks identified, assessed, and projected may not make it into the RMMM plan—they don’t fall into the critical 20 percent (the risks with highest project priority).

第 545 页Gamification 6被建议作为一种鼓励软件开发人员在质量和风险管理等领域遵循流程合规程序的方法 [Ped14]。典型的游戏化方法可能会向每个开发人员授予积分、徽章或其他非金钱奖励,并利用公共排行榜显示每个人在开发团队中的排名。如果这种方法可以基于自动数据收集(例如,跟踪对软件存储库的承诺数量)来实施,那么它可以是一种经济有效的方法,可以确保所有团队成员都在监视旨在触发缓解措施的风险因素措施防止风险演变成灾难所需的步骤[Baj11]。需要注意的是:您必须确保团队成员不会因为在流程中注入问题等行为而获得奖励,这样他们就可以因减轻他们造成的问题而获得徽章 [Bri13]。

Page 545Gamification6 has been suggested as an approach to encouraging software developers to follow process compliance procedures in the areas like quality and risk management [Ped14]. A typical gamification approach might award points, badges, or other nonmonetary awards to each developer and make use of a public leader board showing each person’s ranking within the development group. If such an approach can be implemented based on automatic data collection (e.g., tracking the number of commitments to the software repository), it can be a cost-effective way of ensuring all team members are monitoring the risk factor measures intended to trigger the mitigation steps required to prevent the risk from becoming a disaster [Baj11]. A word of caution: You must ensure that members of the team are not rewarded for doing things like injecting problems into the process, so they can earn badges for mitigating the problems they caused [Bri13].

风险不仅限于软件项目本身。软件成功开发并交付给客户后,可能会出现风险。这些风险通常与现场软件故障的后果相关。

Risk is not limited to the software project itself. Risks can occur after the software has been successfully developed and delivered to the customer. These risks are typically associated with the consequences of software failure in the field.

软件安全和危害分析(例如,[Fir15]、[Har12a]、[Lev12])是软件质量保证活动(第 17 章),重点是识别和评估可能对软件产生负面影响并导致整个系统发生故障的潜在危害。失败。如果可以在软件工程过程的早期识别危险,则可以指定软件设计功能来消除或控制潜在危险。

Software safety and hazard analysis (e.g., [Fir15], [Har12a], [Lev12]) are software quality assurance activities (Chapter 17) that focus on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If hazards can be identified early in the software engineering process, software design features can be specified that will either eliminate or control potential hazards.

26.7 RMMM计划

26.7 The RMMM Plan

风险管理策略可以包含在软件项目计划中,或者风险管理步骤可以组织成单独的风险缓解、监控和管理计划。RMMM 计划记录了作为风险分析一部分执行的所有工作,并由项目经理用作总体项目计划的一部分。

A risk management strategy can be included in the software project plan, or the risk management steps can be organized into a separate risk mitigation, monitoring, and management plan. The RMMM plan documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan.

一些软件团队不开发正式的 RMMM 文档。相反,每个风险都使用风险信息表(RIS)单独记录[Wil97]。在大多数情况下,RIS 使用云数据库系统进行维护,以便可以轻松完成创建和信息输入、优先级排序、搜索和其他分析。这种方法可能有助于支持风险管理流程的游戏化。它还将促进与所有公司软件团队共享风险信息表。RIS 的格式如图26.3所示。

Some software teams do not develop a formal RMMM document. Rather, each risk is documented individually using a risk information sheet (RIS) [Wil97]. In most cases, the RIS is maintained using a cloud database system so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily. This approach might lend itself to supporting gamification of the risk management process. It would also facilitate the sharing of the risk information sheets to all the company software teams. The format of the RIS is illustrated in Figure 26.3.

图26.3 风险信息

Figure 26.3 Risk information sheet

一旦 RMMM 被记录下来并且项目开始,风险缓解和监控步骤就开始了。正如我们已经讨论过的,风险缓解是一种避免问题的活动。风险监控是一项项目跟踪活动,具有三个主要目标: (1) 评估预测的风险是否确实发生;(2) 确保正确应用为风险定义的风险规避步骤;(3) 收集可用于未来风险分析的信息。在许多情况下,项目期间发生的问题可以追溯到多个风险。风险监控的另一项工作是尝试分配来源[什么风险导致了整个项目的哪些问题]。

Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence. As we have already discussed, risk mitigation is a problem avoidance activity. Risk monitoring is a project tracking activity with three primary objectives: (1) to assess whether predicted risks do, in fact, occur; (2) to ensure that risk aversion steps defined for the risk are being properly applied; and (3) to collect information that can be used for future risk analysis. In many cases, the problems that occur during a project can be traced to more than one risk. Another job of risk monitoring is to attempt to allocate origin [what risk(s) caused which problems throughout the project].

第 547 页

Page 547

26.8 总结

26.8 Summary

每当软件项目需要承担很多责任时,常识就决定了风险分析。然而,大多数软件项目经理即使真的这样做,也是非正式和肤浅的。花在识别、分析和管理风险上的时间可以通过多种方式得到回报——减少项目期间的动荡,提高跟踪和控制项目的能力,以及在问题发生之前做好计划所带来的信心。

Whenever a lot is riding on a software project, common sense dictates risk analysis. And yet, most software project managers do it informally and superficially, if they do it at all. The time spent identifying, analyzing, and managing risk pays itself back in many ways—less upheaval during the project, a greater ability to track and control a project, and the confidence that comes with planning for problems before they occur.

风险分析可以消耗大量的项目规划工作。识别、预测、评估、管理和监控都需要时间。但这种努力是值得的。引用2500年前中国将军孙子的话来说,“知己知彼,百战不殆”。对于软件项目经理来说,敌人就是风险。

Risk analysis can absorb a significant amount of project planning effort. Identification, projection, assessment, management, and monitoring all take time. But the effort is worth it. To quote Sun Tzu, a Chinese general who lived 2,500 years ago, “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” For the software project manager, the enemy is risk.

第 548 页

Page 548

问题与思考点

Problems and Points to Ponder

26.1。提供其他领域的五个示例来说明与反应性风险策略相关的问题。

26.1. Provide five examples from other fields that illustrate the problems associated with a reactive risk strategy.

26.2. 描述“已知风险”和“可预测风险”之间的区别。

26.2. Describe the difference between “known risks” and “predictable risks.”

26.3。您是一家大型软件公司的项目经理。您被要求领导一个团队,寻求构建将虚拟现实硬件与最先进的软件相结合的突破性产品。为项目创建风险表。

26.3. You’re the project manager for a major software company. You have been asked to lead a team seeking to build a breakthrough product that combines virtual reality hardware with state-of-the-art software. Create a risk table for the project.

26.4。针对图 26.1中提到的三种风险制定风险缓解策略和具体风险缓解活动。

26.4. Develop a risk mitigation strategy and specific risk mitigation activities for three of the risks noted in Figure 26.1.

26.5。针对图 26.1中提到的三种风险制定风险监控策略和具体风险监控活动。请务必确定您将监控的因素,以确定风险发生的可能性是变得更大还是更小。

26.5. Develop a risk monitoring strategy and specific risk monitoring activities for three of the risks noted in Figure 26.1. Be sure to identify the factors that you’ll be monitoring to determine whether the risk is becoming more likely or less likely to occur.

26.6。针对图 26.1中提到的三种风险制定风险管理策略和具体风险管理活动。

26.6. Develop a risk management strategy and specific risk management activities for three of the risks noted in Figure 26.1.

26.7。尝试细化图 26.1中指出的三个风险,然后为每个风险创建风险信息表。

26.7. Attempt to refine three of the risks noted in Figure 26.1, and then create risk information sheets for each.

26.8。当成本/LOC 为 16 美元且概率为 60% 时,重新计算第 26.4.2 节中讨论的风险暴露。

26.8. Recompute the risk exposure discussed in Section 26.4.2 when cost/LOC is $16 and the probability is 60 percent.

26.9。您能否想到一种高概率、高影响风险不会被视为 RMMM 计划一部分的情况?

26.9. Can you think of a situation in which a high-probability, high-impact risk would not be considered as part of your RMMM plan?

26.10。描述五个软件应用领域,其中软件安全和危害分析将成为主要关注点。

26.10. Describe five software application areas in which software safety and hazard analysis would be a major concern.

1 100% 可能的风险是对软件项目的限制。

1 A risk that is 100 percent probable is a constraint on the software project.

2风险表可以作为电子表格模型来实施。这使得条目的操作和排序变得容易。

2 The risk table can be implemented as a spreadsheet model. This enables easy manipulation and sorting of the entries.

3如果某一风险成分对项目更为重要,则可以使用加权平均值。

3 A weighted average can be used if one risk component has more significance for a project.

4模糊逻辑是一种逻辑,它不仅仅可以识别简单的真值和假值(与您在离散数学课程中学习过的命题逻辑不同)。通过模糊逻辑,命题可以用真假程度来表示。例如,“任何有条纹的动物都是老虎”这一说法可能只有 50% 的可能性是正确的。事实证明,模糊逻辑在涉及不完整或不确定信息的决策的人工智能应用中特别有用。

4 Fuzzy logic is a type of logic that recognizes more than simple true and false values (unlike the propositional logic you may have studied in a discrete mathematics class). With fuzzy logic, propositions can be represented with degrees of truthfulness and falsehood. For example, the statement, any animal with stripes is a tiger might only be 50% likely to be true. Fuzzy logic has proved to be particularly useful in artificial intelligence applications that involve making decisions involving incomplete or uncertain information.

5如果您有进一步的兴趣,[Ben10b] 中提供了对风险成本更数学的处理。

5 If you have further interest, a more mathematical treatment of the cost of risk is presented in [Ben10b].

6德特丁等人。将游戏化定义为在非游戏环境中使用游戏设计元素来增加任务的动力和注意力[Det11]。值得注意的是,这个定义并不是指玩游戏,而是指在其他情况下使用游戏设计元素。

6 Deterding et al. defined gamification as the use of game design elements in nongame settings to increase motivation and attention on a task [Det11]. It is important to note that this definition does not refer to the playing of games, but rather the use of game design elements in other contexts.

第549页

Page 549

章节

chapter

27软件支持策略

27 A Strategy for Software Support

无论其应用领域、规模或复杂性如何,计算机软件都会随着时间的推移而发展。变革推动了这一过程。对于计算机软件来说,当错误被纠正、软件适应新环境、客户请求新特性或功能、以及应用程序被重新设计以在现代环境中提供优势时,就会发生变化。当开发人员让利益相关者参与需求收集和原型演化过程时,软件支持实际上就开始了(图27.1)。软件支持以停止使用系统的决定结束。

Regardless of its application domain, its size, or its complexity, computer software will evolve over time. Change drives this process. For computer software, change occurs when errors are corrected, when the software is adapted to a new environment, when customers request new features or functions, and when the application is reengineered to provide benefit in a modern context. Software support actually begins when the developers involve stakeholders in the requirements gathering and prototype evolution process (Figure 27.1). Software support ends with the decision to retire the system from active use.

图27.1 软件原型演化过程模型

Figure 27.1 Software prototype evolution process model

第 550 页在过去的 40 年里,Manny Lehman(例如,[Leh97a])和他的同事对工业级软件和系统进行了详细分析,努力开发软件演化的统一理论这项工作的细节超出了本书的范围,但值得简要提及其中一些定律 [Leh97b]:

Page 550Over the past 40 years, Manny Lehman (e.g., [Leh97a]) and his colleagues have performed detailed analyses of industry-grade software and systems in an effort to develop a unified theory for software evolution. The details of this work are beyond the scope of this book, but a brief mention of some of these laws [Leh97b] is worthwhile:

持续变化定律(1974)。已经在现实世界的计算环境中实现并因此随着时间的推移而发展的软件(称为E 型系统)必须不断进行调整,否则它们会逐渐变得不太令人满意。

Law of continuing change (1974). Software that has been implemented in a real-world computing context and will therefore evolve over time (called E-type systems) must be continually adapted else they become progressively less satisfactory.

复杂性递增定律(1974)。随着 E 型系统的发展,其复杂性会不断增加,除非做出维护或减少其复杂性的工作。

Law of increasing complexity (1974). As an E-type system evolves its complexity increases unless work is done to maintain or reduce it.

熟悉守恒定律(1980)。随着 E 型系统的发展,所有与之相关的系统,例如开发人员、销售人员、用户,都必须保持对其内容和行为的了解,以实现令人满意的发展。过度的增长会削弱这种知识。因此,随着系统的发展,平均增量增长保持不变。

Law of conservation of familiarity (1980). As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain knowledge of its content and behavior to achieve satisfactory evolution. Excessive growth diminishes that knowledge. Hence the average incremental growth remains invariant as the system evolves.

持续增长定律(1980)。E 型系统的功能内容必须不断增加,以维持用户在其生命周期内的满意度。

Law of continuing growth (1980). The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.

质量下降定律(1996)。除非严格维护并适应运行环境的变化,否则E型系统的质量将会出现下降。

Law of declining quality (1996). The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.

雷曼和他的同事定义的定律是软件工程师现实的固有部分。在本章中,我们将讨论软件支持的挑战,包括延长遗留系统有效寿命所需的维护和演进活动。

The laws that Lehman and his colleagues have defined are an inherent part of a software engineer’s reality. In this chapter, we’ll discuss the challenges of software support including maintenance and evolution activities that are required to extend the effective life of legacy systems.

27.1 软件支持

27.1 Software Support

软件支持可以被认为是一项总括活动,其中包括我们在本书中已经讨论过的许多活动:变更管理(第22章)、主动风险管理(第26章)、流程管理(第25章)、配置管理(第22章)、质量保证(第 17 章)和发布管理(第 4 章)。发布管理是将高质量代码更改从开发人员工作区带到最终用户的过程,包括代码更改集成、持续集成、构建系统规范、基础设施即代码以及部署和发布 [Ada16]。最终软件需要退役。图 27.2提供了显示软件产品发布和退役的时间线示例。第551页

Software support can be considered an umbrella activity that includes many activities we have already discussed in this book: change management (Chapter 22), proactive risk management (Chapter 26), process management (Chapter 25), configuration management (Chapter 22), quality assurance (Chapter 17), and release management (Chapter 4). Release management is the process that brings high-quality code changes from a developer’s workspace to the end user, encompassing code change integration, continuous integration, build system specifications, infrastructure-as-code, and deployment and release [Ada16]. Ultimately software needs to be retired. Figure 27.2 provides an example of a time line showing the release and retirement of a software product.Page 551

图27.2迭代 软件支持模型

Figure 27.2 Iterative software support model

为了有效地支持工业级软件,您的组织(或其指定人员)必须能够进行维护活动中的更正、调整和增​​强。但除此之外,组织还必须提供其他重要的支持活动,包括在软件的整个生命周期内持续的运营支持、最终用户支持和重新设计活动。图27.3展示了支持软件发布后的一种模型。

To effectively support industry-grade software, your organization (or its designee) must be capable of making the corrections, adaptations, and enhancements that are part of the maintenance activity. But in addition, the organization must provide other important support activities that include ongoing operational support, end-user support, and reengineering activities over the complete life of the software. Figure 27.3 shows one model for supporting software after it is released.

图27.3软件发布 停用示例

Figure 27.3 Software release and retirement example

第552页软件可支持性的合理定义是

Page 552A reasonable definition of software supportability is

。。。在软件系统的整个产品生命周期内支持软件系统的能力。这意味着满足任何必要的需求或要求,还意味着提供设备、支持基础设施、附加软件、设施、劳动力或维持软件运行并能够满足其功能所需的任何其他资源。[SSO08]

. . . the capability of supporting a software system over its whole product life. This implies satisfying any necessary needs or requirements, but also the provision of equipment, support infrastructure, additional software, facilities, labor, or any other resource required to maintain the software operational and capable of satisfying its function. [SSO08]

从本质上讲,可支持性是在作为软件过程一部分的分析和设计操作期间应考虑的众多质量因素之一。它应该作为需求模型(或规范)的一部分来解决,并随着设计的发展和施工的开始而考虑。应该考虑软件在被新产品取代之前要维护多长时间。

In essence, supportability is one of many quality factors that should be considered during the analysis and design actions that are part of the software process. It should be addressed as part of the requirements model (or specification) and considered as the design evolves and construction commences. There should be some consideration for how long the software will be maintained before it is replaced by a new product.

例如,本书前面已经讨论过在组件和代码级别对软件进行“反 bug”的需求。软件应包含在操作环境中遇到缺陷时帮助支持人员的设施(毫无疑问,缺陷将会遇到)。此外,支持人员应该能够访问包含已遇到的所有缺陷记录的数据库——它们的特征、原因和解决方法。这将使支持人员能够检查“类似”的缺陷,并可能提供一种更快速诊断和纠正的方法。

For example, the need to “antibug” software at the component and code level has been discussed previously in this book. The software should contain facilities to assist support personnel when a defect is encountered in the operational environment (and make no mistake, defects will be encountered). In addition, support personnel should have access to a database that contains records of all defects that have already been encountered—their characteristics, cause, and cure. This will enable support personnel to examine “similar” defects and may provide a means for more rapid diagnosis and correction.

尽管应用程序中遇到的缺陷是一个关键的支持问题,但可支持性还要求提供资源来支持日常的最终用户问题。最终用户支持人员的工作是回答用户有关应用程序安装、操作和使用的疑问。

Although defects encountered in an application are a critical support issue, supportability also demands that resources be provided to support day-to-day end-user issues. The job of end-user support personnel is to answer user queries about the installation, operation, and use of the application.

27.2 软件维护

27.2 Software Maintenance

维护几乎立即开始。软件发布给最终用户,几天之内,错误报告就会过滤回软件工程组织。几周之内,一类用户表示必须更改软件,以适应其环境的特殊需求。几个月后,另一个在该软件发布时不想与该软件有任何关系的企业集团现在认识到它可能会带来意想不到的好处。他们需要一些增强功能才能使其在他们的世界中发挥作用。

Maintenance begins almost immediately. Software is released to end users, and within days, bug reports filter back to the software engineering organization. Within weeks, one class of users indicates that the software must be changed so that it can accommodate the special needs of their environment. And within months, another corporate group that wanted nothing to do with the software when it was released now recognizes that it may provide unexpected benefit. They’ll need a few enhancements to make it work in their world.

软件维护的挑战已经开始。您面临着越来越多的错误修复、适应请求和彻底的增强功能,必须计划、安排并最终完成这些任务。不久之后,队列就变得很长,它所意味着的工作可能会压垮可用的资源。随着时间的推移,您的组织发现维护现有程序花费的金钱和时间比设计新应用程序的花费更多。事实上,软件组织花费 60% 到 70% 的资源来维护已活跃使用多年的产品并不罕见。

The challenge of software maintenance has begun. You’re faced with a growing queue of bug fixes, adaptation requests, and outright enhancements that must be planned, scheduled, and ultimately accomplished. Before long, the queue has grown long, and the work it implies threatens to overwhelm the available resources. As time passes, your organization finds that it’s spending more money and time maintaining existing programs than it is engineering new applications. In fact, it’s not unusual for a software organization to expend as much as 60 to 70 percent of all resources on software maintenance for products that have been in active use for several years.

正如我们在第 22 章中指出的,变化的普遍性是所有软件工作的基础。当建立基于计算机的系统时,变化是不可避免的;因此,你必须开发评估、控制和修改的机制。第553页

As we noted in Chapter 22, the ubiquitous nature of change underlies all software work. Change is inevitable when computer-based systems are built; therefore, you must develop mechanisms for evaluating, controlling, and making modifications.Page 553

在本书中,我们一直强调理解问题(分析)和开发结构良好的解决方案(设计)的重要性。事实上,本书的第 2 部分专门介绍了这些软件工程操作的机制,第 3 部分重点介绍了确保正确完成这些操作所需的技术。分析和设计都会产生一个重要的软件特性,我们称之为可维护性。从本质上讲,可维护性是对现有软件进行纠正、调整或增强的难易程度的定性指标1 。软件工程的大部分内容是构建具有高可维护性的系统。

Throughout this book, we’ve emphasized the importance of understanding the problem (analysis) and developing a well-structured solution (design). In fact, Part 2 of the book is dedicated to the mechanics of these software engineering actions, and Part 3 focuses on the techniques required to be sure you’ve done them correctly. Both analysis and design lead to an important software characteristic that we call maintainability. In essence, maintainability is a qualitative indication1 of the ease with which existing software can be corrected, adapted, or enhanced. Much of what software engineering is about is building systems that exhibit high maintainability.

但什么是可维护性呢?可维护的软件表现出有效的模块化(第9章)。它使用了易于理解的设计模式(第 14 章)。它是使用明确定义的编码标准和约定构建的,从而产生自记录且易于理解的源代码。它经历了各种质量保证技术(本书的第 3 部分),这些技术在软件发布之前发现了潜在的维护问题。它是由软件工程师创建的,他们认识到当必须进行更改时他们可能不在场。因此,软件的设计和实现必须“协助”进行更改的人。

But what is maintainability? Maintainable software exhibits effective modularity (Chapter 9). It makes use of design patterns (Chapter 14) that allow ease of understanding. It has been constructed using well-defined coding standards and conventions, leading to source code that is self-documenting and understandable. It has undergone a variety of quality assurance techniques (Part 3 of this book) that have uncovered potential maintenance problems before the software is released. It has been created by software engineers who recognize that they may not be around when changes must be made. Therefore, the design and implementation of the software must “assist” the person who is making the change.

27.2.1 维护类型

27.2.1 Maintenance Types

第 4 章中,我们讨论了图 27.4中所示的四种维护类型。很明显,纠正性和适应性维护不会添加新功能。在完美维护期间以及可能在预防性维护期间,新功能可能会添加到软件中。

In Chapter 4 we discussed the four types of maintenance shown in Figure 27.4. It is clear that corrective and adaptive maintenance do not add new functionality. It is likely that new functionality will be added to the software during perfective maintenance and possibly during preventative maintenance as well.

图27.4软件维护 类型

Figure 27.4 Types of software maintenance

在本章中,我们将讨论与软件支持过程相关的三大类软件维护:逆向工程、软件重构和软件演化或重新设计。逆向工程是分析软件系统以识别系统的组件及其相互关系并以另一种形式或更高抽象级别创建系统表示的过程(第 27.2.2 节。通常,逆向工程用于在修改系统源代码之前重新发现系统设计元素并重新记录它们。重构是改变软件系统的过程,其方式不改变其外部行为,但改进其内部结构。重构通常用于提高软件产品的质量,使其更易于理解和维护(第 27.4 节)。软件的再工程(进化)是采用现有软件系统并从中生成新系统的过程,该新系统与使用现代软件工程实践创建的软件具有相同的质量[Osb90]。重新设计和软件演化将在第 27.5 节中讨论。第 554 页

In this chapter, we will discuss three broad classes of software maintenance that are relevant to the software support process: reverse engineering, software refactoring, and software evolution or reengineering. Reverse engineering is the process of analyzing a software system to identify the system’s components and their interrelationships and to create representations of the system in another form or at a higher level of abstraction (Section 27.2.2). Often reverse engineering is used to rediscover system design elements and redocument them prior to modifying the system source code. Refactoring is the process of changing a software system in such a way that it does not alter its external behavior but improves its internal structure. Refactoring is often used to improve the quality of a software product and make it easier to understand and easier to maintain (Section 27.4). Reengineering (evolution) of software is the process of taking an existing software system and generating a new system from it that has the same quality as software created using modern software engineering practices [Osb90]. Reengineering and software evolution are discussed in Section 27.5.Page 554

27.2.2 维护任务

27.2.2 Maintenance Tasks

这种情况太常见了:一个应用程序已经满足一家公司的业务需求 10 或 15 年了。在此期间,它已被多次修正、改编和增强。人们怀着最好的意图来完成这项工作,但良好的软件工程实践总是被搁置一边(由于其他事情的紧迫性)。现在应用程序不稳定。它仍然有效,但每次尝试更改时,都会出现意想不到的严重副作用。然而应用程序必须不断发展。该怎么办?

The scenario is all too common: An application has served the business needs of a company for 10 or 15 years. During this time period it has been corrected, adapted, and enhanced many times. People approached this work with the best intentions, but good software engineering practices were always shunted to the side (due to the urgency of other matters). Now the application is unstable. It still works, but every time a change is attempted, unexpected and serious side effects occur. Yet the application must continue to evolve. What to do?

不可维护的软件并不是一个新问题。事实上,近半个世纪以来一直存在的软件维护问题催生了对软件演化和再工程(第 27.5 节)的日益广泛的重视。图 27.5显示了一组应作为受控软件维护过程的一部分完成的通用任务。

Unmaintainable software is not a new problem. In fact, the broadening emphasis on software evolution and reengineering (Section 27.5) has been spawned by software maintenance problems that have been building for almost half a century. Figure 27.5 shows a set of generic tasks that should be completed as part of a controlled software maintenance process.

图27.5软件 维护任务

Figure 27.5 Software maintenance tasks

敏捷过程模型类似于我们在第 4 章中描述的模型,可以在 4 周的冲刺中交付增量原型。可以说,敏捷开发人员处于永久软件支持模式,因为他们在每个软件增量中添加了利益相关者请求的新功能。然而,重要的是要认识到软件开发不是维护。建议由不同的工程师小组来处理这两项任务。Heeager 和 Rose [Hee15] 建议使用九种启发式方法来帮助维护变得更加敏捷。

Agile process models similar to the one we described in Chapter 4 deliver incremental prototypes in 4-week sprints. It can be argued that agile developers are in perpetual software support mode as they add new stakeholder requested features in every software increment. However, it is important to realize that software development is not maintenance. It is advisable for separate groups of engineers to handle these two tasks. Heeager and Rose [Hee15] suggest nine heuristics to help the maintenance become more agile.

  1. 使用冲刺来组织维护工作。您应该平衡让客户满意的目标与开发人员的技术需求。

  2. Use sprints to organize the maintenance work. You should balance the goal of keeping customers happy with the technical needs of the developers.

  3. 通过在维护冲刺计划中纳入他们的时间,允许紧急客户请求中断计划的维护冲刺。

  4. Allow for urgent customer requests to interrupt scheduled maintenance sprints, by including time for them during maintenance sprint planning.

  5. 确保经验丰富的开发人员即使在处理自己的离散任务时也能够指导经验不足的团队成员,从而促进团队学习。

  6. Facilitate team learning by ensuring that more experienced developers are able to mentor less experienced team members even when working on their own discrete tasks.

  7. 第555页允许多个团队成员接受客户提出的请求,并与其他维护团队成员协调处理。

  8. Page 555Allow multiple team members to accept customer requests as they arise and coordinate their processing with the other maintenance team members.

  9. 平衡书面文档的使用与面对面的沟通,以确保明智地利用计划会议时间。

  10. Balance the use of written documentation with face-to-face communication to ensure planning meeting time is used wisely.

  11. 编写非正式用例来补充用于与利益相关者沟通的其他文档。

  12. Write informal use cases to supplement the other documentation being used for communications with stakeholders.

  13. 让开发人员测试彼此的工作(缺陷修复和新功能实现)。这允许共享学习并提高团队成员的产品所有权感。

  14. Have developers test each other’s work (both defect repairs and new feature implementations). This allows for shared learning and improves the feelings of product ownership by the team members.

  15. 确保开发人员有权相互分享知识。这可以激励人们提高技能和知识(让开发人员学习新事物,提高专业技能,更均匀地分配任务)。

  16. Make sure developers are empowered to share knowledge with one another. This can motivate people to improve the skills and knowledge (allows developers to learn new things, improves their professional skills, and distributes tasks more evenly).

  17. 保持会议计划简短、频繁且重点突出。

  18. Keep planning meetings short, frequent, and focused.

27.2.3 逆向工程

27.2.3 Reverse Engineering

在响应任何维护请求之前,软件工程师需要完成的第一个任务是了解需要修改的系统。遗憾的是,所维护的系统通常质量较低且缺乏合理的文档。这就是技术债务的全部内容。技术债务通常是由于开发人员添加功能而没有记录它们或考虑它们对更大的软件系统的影响而引起的。

The first task that needs to be completed by software engineers before responding to any maintenance request is to understand the system that needs to be modified. Sadly, the system being maintained often has low quality and lacks reasonable documentation. This is what technical debt is all about. Technical debt is often caused by developers adding features without documenting them or considering their impact on the larger software system.

逆向工程可用于从源代码中提取设计信息,但该信息的抽象级别、文档的完整性以及人类分析师使用可用工具的舒适程度是高度可变的。逆向工程让人联想到“神奇的老虎机”。您将随意设计的、未记录的源文件输入插槽中,另一端会输出计算机程序的完整设计描述(和完整文档)。不幸的是,魔法插槽并不存在。

Reverse engineering can be used to extract design information from source code, but the abstraction level of this information, the completeness of the documentation, and the degree to which human analysts work comfortably with the available tools, are highly variable. Reverse engineering conjures an image of the “magic slot.” You feed a haphazardly designed, undocumented source file into the slot and out the other end comes a complete design description (and full documentation) for the computer program. Unfortunately, the magic slot doesn’t exist.

逆向工程要求开发人员通过检查旧软件系统(通常未记录)源代码、开发有意义的正在执行的处理规范、所使用的用户界面以及程序数据结构或相关数据库来评估旧软件系统。

Reverse engineering requires developers to evaluate the old software system by examining its (often undocumented) source code, developing a meaningful specification of the processing being performed, the user interface that was used, and the program data structures or associated database.

逆向工程以理解数据。这发生在不同的抽象级别,并且通常是第一个重新设计任务。在某些情况下,第一个逆向工程活动尝试构建 UML 类图。在程序级别,内部程序数据结构通常必须进行逆向工程,作为整体重新设计工作的一部分。在系统级别,全局数据结构(例如,文件、数据库)经常被重新设计以适应新的数据库管理范例(例如,从平面文件到关系或面向对象的数据库系统的转变)。当前全局数据结构的逆向工程为引入新的全系统数据库奠定了基础。

Reverse Engineering to Understand Data. This occurs at different levels of abstraction and is often the first reengineering task. In some cases, the first reverse engineering activity attempts to construct a UML class diagram. At the program level, internal program data structures must often be reverse engineered as part of an overall reengineering effort. At the system level, global data structures (e.g., files, databases) are often reengineered to accommodate new database management paradigms (e.g., the move from flat file to relational or object-oriented database systems). Reverse engineering of the current global data structures sets the stage for the introduction of a new systemwide database.

内部数据结构。内部程序数据的逆向工程技术重点关注对象类的定义。这是通过检查程序代码来实现的,目的是将相关的程序变量分组在一起。在许多情况下,代码中的数据组织会建议几种抽象数据类型。例如,记录结构、文件、列表和其他数据结构通常为可能的类提供初步建议。第556页

Internal Data Structures. Reverse engineering techniques for internal program data focus on the definition of object classes. This is accomplished by examining the program code with the intent of grouping related program variables together. In many cases, the data organization within the code suggests several abstract data types. For example, record structures, files, lists, and other data structures often provide initial suggestions for possible classes.Page 556

数据库结构。无论其逻辑组织和物理结构如何,数据库都允许定义数据对象并支持某种在对象之间建立关系的方法。因此,将一种数据库模式重新设计为另一种数据库模式需要了解现有对象及其关系。

Database Structure. Regardless of its logical organization and physical structure, a database allows the definition of data objects and supports some method for establishing relationships among the objects. Therefore, reengineering one database schema into another requires an understanding of existing objects and their relationships.

以下步骤[Pre94]可用于定义现有数据模型作为重新设计新数据库模型的先驱:(1)构建初始对象模型,(2)确定候选键(检查属性以确定它们是否是用于指向另一个记录或表;充当指针的那些成为候选键),(3) 细化暂定类,(4) 定义概括,以及 (5) 使用类似于 CRC 方法的技术发现关联。一旦知道了前面步骤中定义的信息,就可以应用一系列转换[Pre94]将旧数据库结构映射到新数据库结构。

The following steps [Pre94] may be used to define the existing data model as a precursor to reengineering a new database model: (1) build an initial object model, (2) determine candidate keys (the attributes are examined to determine whether they are used to point to another record or table; those that serve as pointers become candidate keys), (3) refine the tentative classes, (4) define generalizations, and (5) discover associations using techniques that are analogous to the CRC approach. Once information defined in the preceding steps is known, a series of transformations [Pre94] can be applied to map the old database structure into a new database structure.

理解处理过程的逆向工程首先尝试理解并提取源代码所表示的过程抽象。为了理解过程抽象,需要在不同的抽象级别上分析代码:系统、程序、组件、模式和语句。

Reverse engineering to understand processing begins with an attempt to understand and then extract procedural abstractions represented by the source code. To understand procedural abstractions, the code is analyzed at varying levels of abstraction: system, program, component, pattern, and statement.

在进行更详细的逆向工程工作之前,必须了解整个应用程序的整体功能。这为进一步分析奠定了基础,并提供了对较大系统内应用程序之间的互操作性问题的深入了解。组成系统的每个程序都代表了高级细节的功能抽象。创建代表这些功能抽象之间的交互的框图。每个组件执行一些子功能并代表一个定义的过程抽象。为每个组件开发了一个处理叙述。在某些情况下,系统、程序和组件规范已经存在。在这种情况下,将审查规范是否符合现有代码。2

The overall functionality of the entire application must be understood before more detailed reverse engineering work occurs. This establishes a context for further analysis and provides insight into interoperability issues among applications within a larger system. Each of the programs that make up the system represents a functional abstraction at a high level of detail. A block diagram, representing the interaction between these functional abstractions, is created. Each component performs some subfunction and represents a defined procedural abstraction. A processing narrative for each component is developed. In some situations, system, program, and component specifications already exist. When this is the case, the specifications are reviewed for conformance to existing code.2

当考虑组件内部的代码时,事情变得更加复杂。您应该寻找代表通用过程模式的代码部分。在几乎每个组件中,一段代码准备要处理的数据(在模块内),另一段代码进行处理,另一段代码准备处理结果以从组件导出。在每个部分中,您都可以遇到更小的模式;例如,数据验证和边界检查通常发生在准备处理数据的代码部分中。

Things become more complex when the code inside a component is considered. You should look for sections of code that represent generic procedural patterns. In almost every component, a section of code prepares data for processing (within the module), a different section of code does the processing, and another section of code prepares the results of processing for export from the component. Within each of these sections, you can encounter smaller patterns; for example, data validation and bounds checking often occur within the section of code that prepares data for processing.

对于大型系统,逆向工程通常使用半自动化方法完成。自动化工具可用于帮助您理解现有代码的语义。然后,该过程的输出被传递到重组和正向工程工具以完成再造过程。

For large systems, reverse engineering is generally accomplished using a semi-automated approach. Automated tools can be used to help you understand the semantics of existing code. The output of this process is then passed to restructuring and forward engineering tools to complete the reengineering process.

第 557 页作为维护任务的一部分,可能需要进行逆向工程来了解用户界面。复杂的 GUI 已成为各种类型的基于计算机的产品和系统的必备条件。因此,用户界面的重新开发已成为最常见的再工程活动类型之一。但在重建用户界面之前,应该进行逆向工程。

Page 557Reverse engineering to understand user interfaces may need to be done as part of the maintenance task. Sophisticated GUIs have become de rigueur for computer-based products and systems of every type. Therefore, the redevelopment of user interfaces has become one of the most common types of reengineering activity. But before a user interface can be rebuilt, reverse engineering should occur.

要完全理解现有的用户界面,必须指定界面的结构和行为。Merlo 和他的同事 [Mer93] 提出了在 UI 逆向工程开始时必须回答的三个基本问题:

To fully understand an existing user interface, the structure and behavior of the interface must be specified. Merlo and his colleagues [Mer93] suggest three basic questions that must be answered as reverse engineering of the UI commences:

  • 界面必须处理哪些基本操作(例如,击键和鼠标单击)?

  • What are the basic actions (e.g., keystrokes and mouse clicks) that the interface must process?

  • 系统对这些操作的行为响应的简洁描述是什么?

  • What is a compact description of the behavioral response of the system to these actions?

  • “替换”是什么意思,或者更准确地说,这里相关的接口等效概念是什么?

  • What is meant by a “replacement,” or more precisely, what concept of equivalence of interfaces is relevant here?

行为建模符号(第 9 章)可以提供一种方法来回答前两个问题。创建行为模型所需的许多信息可以通过观察现有界面的外部表现来获得。但必须从代码中提取创建行为模型所需的附加信息。

Behavioral modeling notation (Chapter 9) can provide a means for developing answers to the first two questions. Much of the information necessary to create a behavioral model can be obtained by observing the external manifestation of the existing interface. But additional information necessary to create the behavioral model must be extracted from the code.

值得注意的是,替换的 GUI 可能不会完全反映旧界面(事实上,它可能完全不同)。开发一个新的交互隐喻通常是值得的。例如,旧的 UI 会提示用户提供比例因子(范围从 1 到 10)以缩小或放大图形图像。重新设计的 GUI 可能会使用触摸屏手势来完成相同的功能。

It is important to note that a replacement GUI may not mirror the old interface exactly (in fact, it may be radically different). It is often worthwhile to develop a new interaction metaphor. For example, an old UI that prompts the user to provide a scale factor (ranging from 1 to 10) to shrink or magnify a graphical image. A reengineered GUI might use a touch-screen gesture to accomplish the same function.

27.3 主动软件支持

27.3 Proactive Software Support

我们在第 26 章中描述了被动式风险管理和主动式风险管理之间的差异。我们还将预防性维护和完善性维护描述为主动维护活动(第 27.2.1 节)。如果软件工程的目标是及时且经济高效地交付满足客户需求的高质量产品,那么软件支持与其他软件工程活动一样,需要使用托管工作流程,以避免不必要的返工。

We described the differences between reactive and proactive risk management in Chapter 26. We also described preventative maintenance and perfective maintenance as being proactive maintenance activities (Section 27.2.1). If the goal of software engineering is to deliver high-quality products that meet customer needs in a timely and cost-effective manner, then software support, like other software engineering activities, requires the use of managed workflow processes so that unnecessary rework is avoided.

支持软件意味着对其进行调整以满足不断变化的客户需求并修复最终用户报告的缺陷。这项工作可能是法律、合同协议或产品保修所要求的。修复软件可能是一个耗时且成本高昂的过程,因此在问题变得紧急之前预测问题并安排响应客户问题所需的工作非常重要。主动软件支持要求软件工程师创建工具和流程,帮助他们在软件问题出现之前识别和解决它们。主动软件维护和支持的通用流程如图 27.6所示。

Supporting software means adapting it to meet changing customer demands and repairing defects reported by end users. This work may be required by law, by contractual agreement, or via product warranty. Repairing software can be a time-consuming and costly process, and it’s important to anticipate problems and schedule the work required to respond to customer concerns before they become emergencies. Proactive software support requires software engineers to create tools and processes that can help them identify and resolve software issues before they become problems. A generic process for proactive software maintenance and support is shown in Figure 27.6.

图27.6 软件维护与支持流程

Figure 27.6 Software maintenance and support process

主动支持流程类似于风险监控和缓解(第 26.6 节)。开发人员需要寻找表明其软件产品可能存在质量问题的指标。有时,这些问题可以通过改进产品并将其迁移到更新版本来解决(第 27.5 节)。有时可以重组或重构软件(第 27.4 节)以提高其质量并使其更易于维护。在某些情况下,问题非常严重,以至于开发人员需要制定淘汰产品的计划,并在客户放弃产品之前开始创建替代产品。第 558 页

The proactive support process is similar to risk monitoring and mitigation (Section 26.6). Developers need to search for indicators that suggest their software product may have quality problems. Sometimes these problems can be addressed by evolving the product and migrating it to a newer version (Section 27.5). Sometimes the software can be restructured or refactored (Section 27.4) to improve its quality and make it easier to maintain. In some cases, the problems are so severe that the developer will need to make plans to retire the product and begin creating a replacement product before the customers abandon it.Page 558

27.3.1 软件分析的使用

27.3.1 Use of Software Analytics

目前,人工智能方法在软件工程工作中的三个主要用途[Har12b]:概率推理、机器学习和预测以及基于搜索的软件工程。概率推理技术可用于对软件可靠性进行建模(第 17.7.2 节)。机器学习可用于通过预测可能导致这些故障的缺陷的存在来自动化发现软件故障根本原因的过程(第15.4.3节)。基于搜索的软件工程可用于帮助开发人员识别有用的测试用例,以使回归测试更加有效(第 20.3 节)。所有这些人工智能应用程序都使用与我们在第 23 章中讨论的类似的软件分析。

There are currently three dominant uses for artificial intelligence methods in software engineering work [Har12b]: probabilistic reasoning, machine learning and prediction, and search-based software engineering. Probabilistic reasoning techniques can be used to model software reliability (Section 17.7.2). Machine learning can be used to automate the process of discovering root causes of software failures before they occur by predicting the presence of defects likely to cause these failures (Section 15.4.3). Search-based software engineering may be used to assist developers in identifying useful test cases to make regression testing more effective (Section 20.3). All of these AI applications make use of software analytics similar to those we discussed in Chapter 23.

为了使分析有用,它们必须是可操作的,这意味着要花费精力来确定哪些指标由于其预测价值而值得收集,哪些不值得收集。Port 和 Tabor [Por18] 建议分析可用于估计:基于对产品中尚未发现的缺陷的估计的缺陷发现率、操作期间发现缺陷之间的时间以及修复缺陷所需的工作量。了解这些可以在系统发布给最终用户积极使用后分配用于维护系统的成本和时间方面进行更好的规划。重要的是要记住,即使是最好的估计也包含猜测的成分,因此仍然可能会发生意外的失败。第559页

For analytics to be useful they must be actionable, which means expending the effort to determine which measures are worth collecting because of their predictive value and which are not. Port and Tabor [Por18] suggest that analytics can be used to estimate: defect discovery rates based on estimates of yet undiscovered defects present in the product, time between defect discoveries during operation, and effort required to repair defects. Having an understanding of these can allow for better planning in terms of the cost and time that should be allocated for maintaining the system once it is released to the end users for active use. It is important to keep in mind that even the best estimates contain elements of guessing, so unanticipated failures may still occur.Page 559

张和她的同事 [Zha13] 报告了使用软件分析执行主动维护任务时吸取的一些经验教训。

Zhang and her colleagues [Zha13] report several lessons learned when using software analytics for proactive maintenance tasks.

  1. 确保您使用分析来识别有意义的开发问题,否则您将无法得到软件工程师的支持。

  2. Be sure you are using analytics to identify meaningful development problems, or you will get no buy-in from the software engineers.

  3. 分析必须利用应用程序领域知识对开发人员有用(这意味着使用专家来验证分析)。

  4. The analytics must make use of application domain knowledge to be useful to developers (this implies the use of experts to validate the analytics).

  5. 开发分析需要来自目标用户的迭代和及时的反馈。

  6. Developing analytics requires iterative and timely feedback from the intended users.

  7. 确保分析可扩展到更大的问题,并可定制以纳入随着时间的推移而取得的新发现。

  8. Make sure the analytics are scalable to larger problems and customizable to incorporate new discoveries made over time.

  9. 使用的评估标准需要与真实的软件工程实践相关。

  10. Evaluation criteria used needs to be correlated to real software engineering practices.

挖掘软件存储库中的历史信息是获取前面提到的人工智能技术所需的训练信息的一种流行方法[Sun15]。使用这些发现的知识可以帮助开发人员确定他们的软件支持行动的目标。关于分析和数据科学的使用的更多讨论出现在本书的附录 2中。

Mining of the historical information housed in software repositories is a popular way of obtaining the training information needed for the AI techniques mentioned earlier [Sun15]. Using this discovered knowledge helps developers to target their software support actions. Additional discussion of the use of analytics and data science appears in Appendix 2 to this book.

27.3.2 社交媒体的作用

27.3.2 Role of Social Media

许多在线商店(例如 Google Play 或 Apple 的 App Store)允许用户通过发布评级或评论来提供有关应用程序的反馈。在这些评论中找到的反馈可能包含使用场景、错误报告或功能请求。使用自然语言处理和机器学习技术挖掘这些报告可以帮助开发人员识别潜在的维护和软件演化任务[Sun15]。然而,这些信息大部分都是非结构化的,而且信息量太大,如果不使用自动化统计工具来减少信息量并创建可操作的分析来指导支持决策,就很难理解这些信息。

Many online stores such as Google Play or Apple’s App Store allow users to provide feedback on the apps by posting ratings or comments. The feedback found in these reviews may contain usage scenarios, bug reports, or feature requests. Mining these reports using natural language processing and machine learning techniques can help developers identify potential maintenance and software evolution tasks [Sun15]. However, much of this information is unstructured, and there is so much of it that it is hard to make sense of it without the use of automated statistical tools to reduce the sheer volume of information and create actionable analytics to guide support decisions.

许多公司维护 Facebook 页面或 Twitter 源来支持其用户社区。一些公司鼓励其软件产品用户发送程序崩溃信息以供支持团队成员分析。还有一些公司在客户不知情的情况下跟踪其产品的使用方式和地点,这种做法值得怀疑。自动收集大量用户信息非常容易。软件工程师必须抵制以不道德的方式使用这些信息的诱惑。

Many companies maintain Facebook pages or Twitter feeds to support their user communities. Some companies encourage their software product users to send program crash information for analysis by the support team members. Still other companies pursue the questionable practice of tracking how and where their products are being used by their customers without their knowledge. It is very easy to collect a lot of user information automatically. Software engineers must resist the temptation to make use of this information in unethical ways.

27.3.3 支持成本

27.3.3 Cost of Support

在完美的世界中,每个无法维护的程序都将立即退役,并被使用现代软件工程实践开发的高质量、重新设计的应用程序所取代。但我们生活在一个资源有限的世界。软件开发和维护任务消耗了可用于其他业务目的的资源。因此,在组织尝试修改或替换现有应用程序之前,应该执行成本效益分析。第 560 页

In a perfect world, every unmaintainable program would be retired immediately, to be replaced by high-quality, reengineered applications developed using modern software engineering practices. But we live in a world of limited resources. Software evolution and maintenance tasks drain resources that can be used for other business purposes. Therefore, before an organization attempts to modify or replace an existing application, it should perform a cost-benefit analysis.Page 560

Sneed [Sne95] 提出了再造的成本效益分析模型。定义了九个参数:

A cost-benefit analysis model for reengineering has been proposed by Sneed [Sne95]. Nine parameters are defined:

P 1 = 应用程序当前的年度维护成本

P1 = current annual maintenance cost for an application

P 2 = 应用程序当前的年度运营成本

P2 = current annual operations cost for an application

P 3 = 应用程序当前的年度业务价值

P3 = current annual business value of an application

P 4 = 重新设计后预计的年度维护成本

P4 = predicted annual maintenance cost after reengineering

P 5 = 重新设计后预计的年度运营成本

P5 = predicted annual operations cost after reengineering

P 6 = 重组后预测的年度业务价值

P6 = predicted annual business value after reengineering

P 7 = 估计的再造成本

P7 = estimated reengineering costs

P 8 = 预计的再造日历时间

P8 = estimated reengineering calendar time

P 9 = 再造风险系数(P 9 = 1.0 为名义值)

P9 = reengineering risk factor (P9 = 1.0 is nominal)

L = 系统的预期寿命

L = expected life of the system

与持续维护候选应用程序(即不执行重新设计)相关的成本可以定义为

The cost associated with continuing maintenance of a candidate application (i.e., reengineering is not performed) can be defined as

C维护= [ P 3 − ( P 1 + P 2 )] × L (27.1)

Cmaint = [P3 − (P1 + P2)] × L (27.1)

与再设计相关的成本使用以下关系定义:

The costs associated with reengineering are defined using the following relationship:

C reeng = P 6 − ( P 4 + P 5 ) × ( LP 8 ) − ( P 7 × P 9 )(27.2)

Creeng = P6 − (P4 + P5) × (LP8) − (P7 × P9) (27.2)

使用方程(27.1)(27.2)中提出的成本,再造的总体效益可以计算为

Using the costs presented in Equations (27.1) and (27.2), the overall benefit of reengineering can be computed as

成本效益 = C reengC maint (27.3)

Cost benefit = CreengCmaint (27.3)

这些等式中提出的成本效益分析可以对所有被确定为发展或退役候选者的高优先级应用程序执行(第 27.5 节)。那些显示出最高成本效益的应用程序可以作为主动维护或演进的目标,而其他应用程序的工作可以推迟到资源可用为止。

The cost-benefit analysis presented in these equations can be performed for all high-priority applications identified as candidates to evolve or retire (Section 27.5). Those applications that show the highest cost-benefit can be targeted for proactive maintenance or evolution, while work on other applications can be postponed until resources are available.

27.4 重构

27.4 Refactoring

软件重构(也称为重组)修改源代码和/或数据,以使其能够适应未来的变化。一般来说,重构不会修改整个程序架构。它倾向于关注各个模块的设计细节以及模块内定义的本地数据结构。如果重构工作超出了模块边界并包含了软件架构,那么重构就变成了正向工程(第 27.5 节)。

Software refactoring (also known as restructuring) modifies source code and/or data in an effort to make it amenable to future changes. In general, refactoring does not modify the overall program architecture. It tends to focus on the design details of individual modules and on local data structures defined within modules. If the refactoring effort extends beyond module boundaries and encompasses the software architecture, restructuring becomes forward engineering (Section 27.5).

当应用程序的基本架构稳固时,即使技术内部需要改进,也会发生重构。当软件的主要部分可以使用并且只有所有模块和数据的子集需要大量修改时,就会启动它。3第561页

Refactoring occurs when the basic architecture of an application is solid, even though technical internals need work. It is initiated when major parts of the software are serviceable and only a subset of all modules and data need extensive modification.3Page 561

27.4.1 数据重构

27.4.1 Data Refactoring

在开始数据重构之前,应进行称为源代码分析的逆向工程活动。所有包含数据定义、文件描述、I/O 和接口描述的编程语言语句都会被评估。目的是提取数据项和对象,获取数据流信息,并了解已实现的现有数据结构。此活动有时称为数据分析

Before data refactoring can begin, a reverse engineering activity called source code analysis should be conducted. All programming language statements that contain data definitions, file descriptions, I/O, and interface descriptions are evaluated. The intent is to extract data items and objects, to get information on data flow, and to understand the existing data structures that have been implemented. This activity is sometimes called data analysis.

数据分析完成后,数据重新设计就开始了。数据记录标准化步骤以其最简单的形式阐明数据定义,以实现现有数据结构或文件格式内的数据项名称或物理记录格式之间的一致性。另一种形式的重新设计称为数据名称合理化,可确保所有数据命名约定符合本地标准,并且当数据流经系统时消除别名。

Once data analysis has been completed, data redesign commences. In its simplest form, a data record standardization step clarifies data definitions to achieve consistency among data item names or physical record formats within an existing data structure or file format. Another form of redesign, called data name rationalization, ensures that all data naming conventions conform to local standards and that aliases are eliminated as data flow through the system.

当重构超越标准化和合理化时,会对现有数据结构进行物理修改,以使数据设计更加有效。这可能意味着从一种文件格式到另一种文件格式的转换,或者在某些情况下,从一种类型的数据库到另一种类型的转换。

When refactoring moves beyond standardization and rationalization, physical modifications to existing data structures are made to make the data design more effective. This may mean a translation from one file format to another, or in some cases, translation from one type of database to another.

27.4.2 代码重构

27.4.2 Code Refactoring

执行代码重构是为了产生比原始程序具有相同功能但质量更高的设计。目标是采用“意大利面条碗”代码并得出符合第 15 章和第 17 章讨论的质量因素的设计。

Code refactoring is performed to yield a design that produces the same function but with higher quality than the original program. The objective is to take “spaghetti-bowl” code and derive a design that conforms to the quality factors discussed in Chapters 15 and 17.

还提出了与重构工具一起使用的其他重构技术。一种方法可能依赖于反模式的使用(第 14.5 节),既可以识别不良的代码设计实践,也可以建议可能的解决方案来减少耦合和提高内聚性 [Bro98]。尽管代码重构可以缓解与调试或小更改相关的直接问题,但这并不是重新设计。只有当数据和架构也被重构时,才能获得真正的好处。

Other restructuring techniques have also been proposed for use with refactoring tools. One approach might rely on the use of anti-patterns (Section 14.5), both to identify bad code design practices and suggest possible solutions to reduce coupling and improve cohesion [Bro98]. Although code refactoring can alleviate immediate problems associated with debugging or small changes, it is not reengineering. Real benefit is achieved only when data and architecture are refactored as well.

27.4.3 架构重构

27.4.3 Architecture Refactoring

我们在第 10 章中指出,对已投入生产的软件产品进行架构更改可能是一个成本高昂且耗时的过程。然而,当程序的控制流看起来像一碗意大利面条的图形时,“模块”有 2,000 条语句长,290,000 条源语句中几乎没有有意义的注释行,并且不需要修改其他文档来适应不断变化的用户需求,可能需要将架构重构视为设计权衡之一。一般来说,对于像这样混乱的程序,您有以下选择:

We made the point in Chapter 10 that making architectural changes to a software product already in production can be a costly and time-consuming process. However, when a program with control flow that looks like the graphic equivalent of a bowl of spaghetti, with “modules” that are 2,000 statements long, with few meaningful comment lines in 290,000 source statements and no other documentation must be modified to accommodate changing user requirements, it may be desirable to consider architectural refactoring as one of the design trade-offs. In general, for a messy program like this you have the following options:

  1. 您可以在一次又一次的修改中挣扎,与临时设计和纠结的源代码作斗争,以实现必要的更改。

  2. You can struggle through modification after modification, fighting the ad hoc design and tangled source code to implement the necessary changes.

  3. 您可以尝试了解程序更广泛的内部工作原理,以便更有效地进行修改。

  4. You can attempt to understand the broader inner workings of the program in an effort to make modifications more effectively.

  5. 您可以修改(重新设计、重新编码和测试)软件中需要修改的部分,对所有修改的部分应用有意义的软件工程方法。

  6. You can revise (redesign, recode, and test) those portions of the software that require modification, applying a meaningful software engineering approach to all revised segments.

  7. 第562页您可以完全重做(重新设计、重新编码和测试)整个程序,使用重新设计工具来帮助理解当前的设计。

  8. Page 562You can completely redo (redesign, recode, and test) the complete program, using reengineering tools to assist in understanding the current design.

没有单一的“正确”选项。即使其他选项更可取,情况也可能决定第一个选项。

There is no single “correct” option. Circumstances may dictate the first option even if the others are more desirable.

开发或支持组织不是等到收到维护请求,而是使用库存分析的结果来选择一个程序,该程序 (1) 将在预选的年限内继续使用,(2) 目前正在成功使用,并且(3) 可能在不久的将来进行重大修改或增强。然后,应用选项 2、3 或 4。我们将在27.5 节中讨论软件演化和再造。

Rather than waiting until a maintenance request is received, the development or support organization uses the results of inventory analysis to select a program that (1) will remain in use for a preselected number of years, (2) is currently being used successfully, and (3) is likely to undergo major modification or enhancement in the near future. Then, option 2, 3, or 4 is applied. We will discuss software evolution and reengineering in Section 27.5.

27.5 软件演化

27.5 Software Evolution

乍一看,在工作版本已经存在的情况下重新开发大型程序的建议似乎相当奢侈。重新设计需要时间、成本高昂,并且会占用原本可能被用于眼前问题的资源。出于所有这些原因,再造不是几个月甚至几年就能完成的。

At first glance, the suggestion that you redevelop a large program when a working version already exists may seem quite extravagant. Reengineering takes time, it has significant cost, and it absorbs resources that might be otherwise occupied on immediate concerns. For all these reasons, reengineering is not accomplished in a few months or even a few years.

软件系统的再造是一项将吸收软件工程资源多年的活动。这就是为什么每个组织都需要一个务实的软件重组策略。如果时间和资源短缺,您可以考虑将帕累托原则应用于要重新设计的软件,并将重新设计过程应用于占80%问题的20%软件。

Reengineering of software systems is an activity that will absorb software engineering resources for many years. That’s why every organization needs a pragmatic strategy for software reengineering. If time and resources are in short supply, you might consider applying the Pareto principle to the software that is to be reengineered and apply the reengineering process to the 20 percent of the software that accounts for 80 percent of the problems.

在做出判断之前,请考虑以下论点。维护一行源代码的成本可能是该行初始开发成本的 20 到 40 倍。此外,利用现代设计理念重新设计软件架构(程序和/或数据结构),可以极大地方便将来的维护。用于重新设计或软件改进的自动化工具将使某些部分的工作变得更加容易。由于该软件的原型已经存在,因此开发效率应该远高于平均水平。用户现在已经体验了该软件。因此,可以更轻松地确定新的要求和变化的方向。在这种渐进式预防性维护结束时,开发人员将获得完整的软件配置(文档、程序和数据)。

Before passing judgment, consider the following arguments. The cost to maintain one line of source code may be 20 to 40 times the cost of initial development of that line. In addition, redesign of the software architecture (program and/or data structure), using modern design concepts, can greatly facilitate future maintenance. Automated tools for reengineering or software evolution will make some part of the job easier. Because a prototype of the software already exists, development productivity should be much higher than average. The user now has experience with the software. Therefore, new requirements and the direction of change can be ascertained with greater ease. At the end of this evolutionary preventive maintenance, the developers will end up with a complete software configuration (documents, programs, and data).

再造工程是一种重建活动。为了更好地理解它,请考虑一个类似的活动:重建房屋。考虑以下情况。您在另一个州购买了房子。你从未真正见过这处房产,但你以惊人的低价买下了它,并警告说它可能需要完全重建。你将如何进行?

Reengineering is a rebuilding activity. To better understand it, consider an analogous activity: the rebuilding of a house. Consider the following situation. You’ve purchased a house in another state. You’ve never actually seen the property, but you acquired it at an amazingly low price, with the warning that it might have to be completely rebuilt. How would you proceed?

  • 在开始重建之前,检查房子似乎是合理的。为了确定是否需要重建,您(或专业检查员)将创建一个标准列表,以便您的检查能够系统化。

  • Before you can start rebuilding, it would seem reasonable to inspect the house. To determine whether it is in need of rebuilding, you (or a professional inspector) would create a list of criteria so that your inspection would be systematic.

  • 在拆除并重建整个房屋之前,请确保结构坚固。如果房屋结构完好,则可以在不重建的情况下进行“改造”(成本低得多,时间短得多)。

  • Before you tear down and rebuild the entire house, be sure that the structure is weak. If the house is structurally sound, it may be possible to “remodel” without rebuilding (at much lower cost and in much less time).

  • 第563页在开始重建之前,请确保您了解原始版本是如何构建的。看看墙后面。了解接线、管道和内部结构。即使你把它们全部扔掉,你所获得的洞察力也会在你开始建造时为你带来好处。

  • Page 563Before you start rebuilding, be sure you understand how the original was built. Take a peek behind the walls. Understand the wiring, the plumbing, and the structural internals. Even if you trash them all, the insight you’ll gain will serve you well when you start construction.

  • 如果您开始重建,请仅使用最现代、最耐用的材料。现在这可能会花费更多一些,但它将帮助您避免以后进行昂贵且耗时的维护。

  • If you begin to rebuild, use only the most modern, long-lasting materials. This may cost a bit more now, but it will help you to avoid expensive and time-consuming maintenance later.

  • 如果您决定重建,请遵守纪律。使用将在今天和未来带来高质量的实践。

  • If you decide to rebuild, be disciplined about it. Use practices that will result in high quality—today and in the future.

尽管这些原则侧重于房屋的重建,但它们同样适用于不断发展的基于计算机的系统和应用程序。

Although these principles focus on the rebuilding of a house, they apply equally well to the evolving computer-based systems and applications.

为了实现这些原则,您可以使用循环流程模型进行重新设计,如图27.7所示。该模型定义了六项活动。因为它是周期性的,所以所提出的每项活动都可以根据需要经常重新审视。对于任何特定周期,流程可以在这些活动中的任何一项之后终止。

To implement these principles, you can use a cyclical process model for reengineering like the one shown in Figure 27.7. This model defines six activities. Because it is cyclical, each of the activities presented may be revisited as often as needed. For any particular cycle, the process can terminate after any one of these activities.

27.7 软件再造过程模型

Figure 27.7 A software reengineering process model

27.5.1 库存分析

27.5.1 Inventory Analysis

每个软件组织都应该拥有所有应用程序的清单。清单只不过是一个电子表格模型,其中包含提供每个活动应用程序的详细描述(例如,大小、寿命、业务关键性)的信息。通过根据业务关键性、寿命、当前可维护性和可支持性以及其他本地重要标准对这些信息进行排序,重新设计的候选者就出现了。然后可以将资源分配给候选应用程序以进行重新设计工作。第564页

Every software organization should have an inventory of all applications. The inventory can be nothing more than a spreadsheet model containing information that provides a detailed description (e.g., size, age, business criticality) of every active application. By sorting this information according to business criticality, longevity, current maintainability and supportability, and other locally important criteria, candidates for reengineering appear. Resources can then be allocated to candidate applications for reengineering work.Page 564

值得注意的是,应定期重新审查库存。应用程序的状态(例如,业务关键性)可能会随着时间而变化,因此,重新设计的优先级将会发生变化。

It is important to note that the inventory should be revisited on a regular basis. The status of applications (e.g., business criticality) can change as a function of time, and as a result, priorities for reengineering will shift.

27.5.2 文档重组

27.5.2 Document Restructuring

薄弱的文档是许多遗留系统的标志。但你能做什么呢?你有什么选择?在某些情况下,在不存在文档的情况下创建文档成本太高。如果该软件有效,那就顺其自然吧!在其他情况下,必须创建一些文档,但仅限于进行更改时。如果发生修改,请记录下来。最后,在某些情况下,必须对关键系统进行完整记录,但即使在这种情况下,文档也应达到最低限度。您的软件组织必须选择最适合每种情况的文档选项。

Weak documentation is the trademark of many legacy systems. But what can you do about it? What are your options? In some cases, creating documentation when none exists is simply too costly. If the software works, let it be! In other cases, some documentation must be created, but only when changes are made. If a modification occurs, document it. Finally, there are situations in which a critical system must be fully documented, but even here, documents should achieve an essential minimum. Your software organization must choose the documentation option that is most appropriate for each case.

27.5.3 逆向工程

27.5.3 Reverse Engineering

软件逆向工程是分析程序的过程,旨在以比源代码更高的抽象级别创建程序的表示。逆向工程是设计恢复的过程。逆向工程工具从现有程序中提取数据、架构和程序设计信息。

Reverse engineering for software is the process of analyzing a program in an effort to create a representation of the program at a higher level of abstraction than source code. Reverse engineering is a process of design recovery. Reverse engineering tools extract data, architectural, and procedural design information from an existing program.

27.5.4 代码重构

27.5.4 Code Refactoring

最常见的重新设计类型(实际上,在这种情况下,重新设计一词的使用是有问题的)是代码重构。一些遗留系统具有可靠的程序架构,但各个模块的编码方式使其难以理解、测试和维护。在这种情况下,可以重组可疑模块中的代码。

The most common type of reengineering (actually, the use of the term reengineering is questionable in this case) is code refactoring. Some legacy systems have a solid program architecture, but individual modules were coded in a way that makes them difficult to understand, test, and maintain. In such cases, the code within the suspect modules can be restructured.

为了完成此活动,使用重组工具对源代码进行分析。违反良好设计实践的行为会被注意到,然后代码会被重构,甚至用更现代的编程语言重写。对重构后的代码进行审查和测试,以确保没有引入异常。更新了内部代码文档。

To accomplish this activity, the source code is analyzed using a restructuring tool. Violations of good design practices are noted, and code is then refactored or even rewritten in a more modern programming language. The resultant refactored code is reviewed and tested to ensure that no anomalies have been introduced. Internal code documentation is updated.

27.5.5 数据重构

27.5.5 Data Refactoring

数据架构薄弱的程序将难以适应和增强。事实上,对于许多应用程序来说,信息架构与程序的长期生存能力比源代码本身更重要。

A program with weak data architecture will be difficult to adapt and enhance. In fact, for many applications, information architecture has more to do with the long-term viability of a program than the source code itself.

与发生在相对较低的抽象级别的代码重组不同,数据重组是一种全面的重新设计活动。在大多数情况下,数据重组始于逆向工程活动。剖析当前的数据架构,并定义必要的数据模型。识别数据对象和属性,并审查现有数据结构的质量。

Unlike code restructuring, which occurs at a relatively low level of abstraction, data restructuring is a full-scale reengineering activity. In most cases, data restructuring begins with a reverse engineering activity. Current data architecture is dissected, and necessary data models are defined. Data objects and attributes are identified, and existing data structures are reviewed for quality.

当数据结构较弱时(例如,当前实现的是平面文件,而关系方法将大大简化处理),则需要重新设计数据。

When data structure is weak (e.g., flat files are currently implemented, when a relational approach would greatly simplify processing), the data are reengineered.

第565页由于数据架构对程序架构和填充它的算法有很大的影响,因此数据的更改必然会导致架构或代码级的更改。

Page 565Because data architecture has a strong influence on program architecture and the algorithms that populate it, changes to the data will invariably result in either architectural or code-level changes.

27.5.6 正向工程

27.5.6 Forward Engineering

在理想的情况下,应用程序将使用自动化的“重新设计引擎”来重建。旧程序将被输入引擎,进行分析、重组,然后以展现软件质量最佳方面的形式重新生成。短期内,这样的“引擎”不太可能出现,但供应商已经推出了一些工具,这些工具提供了这些功能的有限子集,可以解决特定的应用程序域(例如,使用特定数据库系统实现的应用程序)。更重要的是,这些再设计工具变得越来越复杂。

In an ideal world, applications would be rebuilt using an automated “reengineering engine.” The old program would be fed into the engine, analyzed, restructured, and then regenerated in a form that exhibited the best aspects of software quality. In the short term, it is unlikely that such an “engine” will appear, but vendors have introduced tools that provide a limited subset of these capabilities that addresses specific application domains (e.g., applications that are implemented using a specific database system). More important, these reengineering tools are becoming increasingly more sophisticated.

正向工程不仅从现有软件中恢复设计信息,而且利用这些信息来改变或重构现有系统,以提高其整体质量。在大多数情况下,重新设计的软件会重新创建现有系统的功能,并添加新功能和/或提高整体性能。在大多数情况下,正向工程并不是简单地创建旧程序的现代版本。相反,新的用户和技术要求被整合到重新设计工作中。重新开发的程序扩展了旧应用程序的功能。

Forward engineering not only recovers design information from existing software but uses this information to alter or reconstitute the existing system in an effort to improve its overall quality. In most cases, reengineered software re-creates the function of the existing system and also adds new functions and/or improves overall performance. In most cases, forward engineering does not simply create a modern equivalent of an older program. Rather, new user and technology requirements are integrated into the reengineering effort. The redeveloped program extends the capabilities of the older application.

27.6 总结

27.6 Summary

软件支持是在应用程序的整个生命周期中发生的持续活动。在支持期间,启动维护操作,纠正缺陷,使应用程序适应不断变化的操作或业务环境,并根据利益相关者的要求实施增强功能。此外,当用户将应用程序集成到他们的个人或业务工作流程中时,他们也会得到支持。

Software support is an ongoing activity that occurs throughout the life cycle of an application. During support, maintenance actions are initiated, defects are corrected, applications are adapted to a changing operational or business environment, enhancements are implemented at the request of stakeholders. In addition, users are supported as they integrate an application into their personal or business work flow.

软件维护和支持活动本质上需要积极主动。最好在客户发现问题并对软件产品不满意之前预测问题并消除其根本原因。软件分析的使用可以帮助软件开发人员在潜在的缺陷和维护问题出现之前识别它们。

Software maintenance and support activities need to be proactive in their nature. It is better to anticipate problems and remove their root causes before the customers find them and become dissatisfied with the software product. The use of software analytics may help software developers identify potential defects and maintenance issues before they become problematic.

在软件层面,再工程检查信息系统和应用程序,目的是重组或重构它们,使其表现出更高的质量。软件演化或再工程包含一系列活动,包括清单分析、文档重组、逆向工程、程序和数据重组以及正向工程。这些活动的目的是创建具有更高质量和更好可维护性的现有程序版本,这些程序将在二十一世纪仍然可行。

At the software level, reengineering examines information systems and applications with the intent of restructuring or reconstructing them so that they exhibit higher quality. Software evolution or reengineering encompasses a series of activities that include inventory analysis, document restructuring, reverse engineering, program and data restructuring, and forward engineering. The intent of these activities is to create versions of existing programs that exhibit higher quality and better maintainability—programs that will be viable well into the twenty-first century.

再造的成本效益可以定量确定。将现状成本(即与现有应用程序的持续支持和维护相关的成本)与重新设计的预计成本以及由此产生的维护和支持成本减少进行比较。几乎在所有程序寿命较长且当前可维护性或可支持性较差的情况下,重新设计都是一种具有成本效益的业务策略。

The cost-benefit of reengineering can be determined quantitatively. The cost of the status quo, that is, the cost associated with ongoing support and maintenance of an existing application, is compared to the projected costs of reengineering and the resultant reduction in maintenance and support costs. In almost every case in which a program has a long life and currently exhibits poor maintainability or supportability, reengineering represents a cost-effective business strategy.

第566页

Page 566

问题与思考点

Problems and Points to Ponder

27.1。软件支持与软件维护有何不同?

27.1. How does software support differ from software maintenance?

27.2。您的讲师将选择班上每个人在本课程中开发的程序之一。与班上的其他人随机交换你的程序。不要解释或演练该程序。现在,在您收到的程序中实施增强功能(由您的讲师指定)。

27.2. Your instructor will select one of the programs that everyone in the class has developed during this course. Exchange your program randomly with someone else in the class. Do not explain or walk through the program. Now, implement an enhancement (specified by your instructor) in the program you have received.

  1. 执行所有软件工程任务,包括简短的演练(但不与程序作者一起)。

  2. Perform all software engineering tasks including a brief walkthrough (but not with the author of the program).

  3. 仔细跟踪测试期间遇到的所有错误。

  4. Keep careful track of all errors encountered during testing.

  5. 讨论你在课堂上的经历。

  6. Discuss your experiences in class.

27.3。创建一个软件再造清单分析清单,并提出一个可应用于现有程序的定量软件评级系统,以选择进行再造的候选程序。您的系统应该超出第 27.3 节中介绍的经济分析范围。

27.3. Create a software reengineering inventory analysis checklist, and propose a quantitative software rating system that could be applied to existing programs in an effort to pick candidate programs for reengineering. Your system should extend beyond the economic analysis presented in Section 27.3.

27.4。建议替代纸张和墨水或传统电子文档,作为文档重组的基础。(提示:考虑可用于传达软件意图的新描述性技术。)

27.4. Suggest alternatives to paper and ink or conventional electronic documentation that could serve as the basis for document restructuring. (Hint: Think of new descriptive technologies that could be used to communicate the intent of the software.)

27.5。一些人认为人工智能技术将提高逆向工程过程的抽象程度。对这个主题进行一些研究(即使用人工智能进行逆向工程),并写一篇简短的论文来表明这一点。

27.5. Some people believe that artificial intelligence technology will increase the abstraction level of the reverse engineering process. Do some research on this subject (i.e., the use of AI for reverse engineering), and write a brief paper that takes a stand on this point.

27.6。为什么随着抽象层次的增加,完整性越来越难以实现?

27.6. Why is completeness difficult to achieve as abstraction level increases?

27.7。为什么主动软件支持比被动缺陷修复更可取?

27.7. Why is proactive software support preferable to reactive defect repair?

27.8。使用通过网络获得的信息,向全班展示三种逆向工程工具的特征。

27.8. Using information obtained via the Web, present characteristics of three reverse engineering tools to your class.

27.9。重构和正向工程之间存在细微的差别。它是什么?

27.9. There is a subtle difference between refactoring and forward engineering. What is it?

27.10。您如何确定第 27.3.3 节中提出的成本效益模型中的P 4P 7

27.10. How would you determine P4 through P7 in the cost-benefit model presented in Section 27.3.3?

1有许多定量指标可以间接指示可维护性(例如,[Sch99]、[SEI02])。

1 There are many quantitative measures that provide an indirect indication of maintainability (e.g., [Sch99], [SEI02]).

2通常,在程序生命历史早期编写的规范永远不会更新。随着更改的进行,代码不再符合规范。

2 Often, specifications written early in the life history of a program are never updated. As changes are made, the code no longer conforms to the specification.

3有时很难区分广泛重构和演化。两者都在重新设计。

3 It is sometimes difficult to make a distinction between extensive refactoring and evolution. Both are reengineering.

第 567 页

Page 567

部分 高级主题

PART Five Advanced Topics

《软件工程:从业者方法》的这一部分中,我们考虑了几个高级主题,这些主题将扩展您对软件工程的理解。以下章节将解决以下问题:

In this part of Software Engineering: A Practitioner’s Approach, we consider several advanced topics that will extend your understanding of software engineering. The following questions are addressed in the chapters that follow:

  • 什么是软件过程改进以及如何利用它来改善软件工程实践的状态?

  • What is software process improvement and how can it be used to improve the state of software engineering practice?

  • 哪些新兴趋势预计会对未来十年的软件工程实践产生重大影响?

  • What emerging trends can be expected to have a significant influence on software engineering practice in the next decade?

  • 软件工程师的未来之路是什么?

  • What is the road ahead for software engineers?

一旦回答了这些问题,您就会了解未来几年可能对软件工程产生深远影响的主题。

Once these questions are answered, you’ll understand topics that may have a profound impact on software engineering in the years to come.

第 568 页

Page 568

章节

chapter

28软件流程改进

28 Software Process Improvement

早在“软件过程改进”一词被广泛使用之前,RSP 就与大公司合作,帮助他们改善软件工程实践的状态。根据他的经验,他写了一本名为“Making Software Engineering Happen”的书[Pre88]。他在那本书的序言中发表了以下评论:

Long before the phrase “software process improvement” was widely used, RSP worked with major corporations to help them improve the state of their software engineering practices. Based on his experiences, he wrote a book titled Making Software Engineering Happen [Pre88]. In the preface of that book he made the following comment:

在过去的十年里,我有机会帮助许多大公司实施软件工程实践。这项工作很困难,而且很少能像人们希望的那样顺利——但当它成功时,其结果是深远的。。。

For the past ten years I have had the opportunity to help a number of large companies implement software engineering practices. The job is difficult and rarely goes as smoothly as one might like—but when it succeeds, the results are profound . . .

但一切并不都是甜蜜和轻松的。许多公司尝试实施软件工程实践并无奈放弃。其他人则半途而废,从未看到上述好处。还有一些人采取了严厉的方式,导致技术人员和管理人员公开反抗,从而导致士气低落。

But all is not sweetness and light. Many companies attempt to implement software engineering practice and give up in frustration. Others do it half-way and never see the benefits noted above. Still others do it in a heavy-handed fashion that results in open rebellion among technical staff and managers and subsequent loss of morale.

第 569 页尽管这些话是三十多年前写的,但在今天仍然同样正确。

Page 569Even though these words were written over three decades ago, they remain equally true today.

多年来,几乎每个主要的软件工程组织都试图“让软件工程成为现实”。有些人实施了个人实践,这有助于提高他们制造的产品的质量和交付的及时性。其他人则建立了一个“成熟”的软件流程来指导他们的技术和项目管理活动。但其他人仍在继续挣扎。他们的做法是偶然的,他们的过程也是临时的。有时候,他们的作品很壮观,但总的来说,每个项目都是一次冒险,没有人知道它的结局是好是坏。

Over the years, virtually every major software engineering organization has attempted to “make software engineering happen.” Some have implemented individual practices that have helped to improve the quality of the product they build and the timeliness of their delivery. Others have established a “mature” software process that guides their technical and project management activities. But others continue to struggle. Their practices are hit-and-miss, and their process is ad hoc. Occasionally, their work is spectacular, but in the main, each project is an adventure, and no one knows whether it will end badly or well.

那么,这两个群体中哪一个需要软件流程改进呢?答案(可能会让您感到惊讶)是两者兼而有之。那些成功实现软件工程的人不能自满。他们必须不断努力改进他们的软件工程方法。那些挣扎的人必须开始他们的进步之路。

So, which of these two cohorts needs software process improvement? The answer (which may surprise you) is both. Those that have succeeded in making software engineering happen cannot become complacent. They must work continually to improve their approach to software engineering. And those that struggle must begin their journey down the road toward improvement.

28.1 什么是SPI?

28.1 What Is SPI?

软件过程改进(SPI)一词包含很多含义。首先,它意味着可以以有效的方式定义有效软件过程的元素;其次,可以根据这些要素评估现有的软件开发组织方法;第三,可以制定有意义的改进策略。SPI 策略将现有的软件开发方法转变为更专注、更可重复、更可靠(就生产产品的质量和交付的及时性而言)。

The term software process improvement (SPI) implies many things. First, it implies that elements of an effective software process can be defined in an effective manner; second, that an existing organizational approach to software development can be assessed against those elements; and third, that a meaningful strategy for improvement can be defined. The SPI strategy transforms the existing approach to software development into something that is more focused, more repeatable, and more reliable (in terms of the quality of the product produced and the timeliness of delivery).

由于 SPI 不是免费的,因此它必须提供投资回报。实施 SPI 策略所需的努力和时间必须以某种可衡量的方式得到回报。为此,改进流程和实践的结果必须减少耗费时间和金钱的软件“问题”。它必须减少交付给最终用户的缺陷数量,减少由于质量问题而导致的返工量,减少与软件维护和支持相关的成本(第27章),并减少软件延迟交付时产生的间接成本。

Because SPI is not free, it must deliver a return on investment. The effort and time that is required to implement an SPI strategy must pay for itself in some measurable way. To do this, the results of improved process and practice must lead to a reduction in software “problems” that cost time and money. It must reduce the number of defects that are delivered to end users, reduce the amount of rework due to quality problems, reduce the costs associated with software maintenance and support (Chapter 27), and reduce the indirect costs that occur when software is delivered late.

28.1.1 SPI 方法

28.1.1 Approaches to SPI

尽管组织可以选择相对非正式的 SPI 方法,但绝大多数组织选择众多 SPI 框架之一。SPI 框架定义了 (1) 如果要实现有效的软件过程,则必须存在一组特征,(2) 评估这些特征是否存在的方法,(3) 总结任何评估结果的机制,以及(4)协助软件组织实施那些被发现薄弱或缺失的过程特征的策略。

Although an organization can choose a relatively informal approach to SPI, the vast majority choose one of a number of SPI frameworks. An SPI framework defines (1) a set of characteristics that must be present if an effective software process is to be achieved, (2) a method for assessing whether those characteristics are present, (3) a mechanism for summarizing the results of any assessment, and (4) a strategy for assisting a software organization in implementing those process characteristics that have been found to be weak or missing.

SPI 框架评估组织软件流程的“成熟度”,并提供成熟度级别的定性指示。事实上,术语“成熟度模型”第 28.1.2 节)经常被应用。SPI 框架包含一个成熟度模型,该模型又包含一组过程质量指标,这些指标提供对导致产品质量的过程质量的总体衡量。第 570 页

An SPI framework assesses the “maturity” of an organization’s software process and provides a qualitative indication of a maturity level. In fact, the term maturity model (Section 28.1.2) is often applied. The SPI framework encompasses a maturity model that in turn incorporates a set of process quality indicators that provide an overall measure of the process quality that will lead to product quality.Page 570

图 28.1提供了典型 SPI 框架的概述。显示了该框架的关键要素及其相互关系。

Figure 28.1 provides an overview of a typical SPI framework. The key elements of the framework and their relationship to one another are shown.

图28.1 SPI 框架的要素

Figure 28.1 Elements of an SPI framework

资料来源:改编自 Rout, Terry,“软件过程评估 - 第 1 部分:概念和入门指南”,Spice,2002 年。

Source: Adapted from Rout, Terry, “Software Process Assessment—Part 1: Concepts and Introductory Guide,” Spice, 2002.

您应该注意,没有通用的 SPI 框架。事实上,组织选择的 SPI 框架反映了组织中支持 SPI 工作的人员。应用 SPI 框架时,组织必须建立机制来:(1) 支持技术转型,(2) 确定组织准备吸收所提议的流程变更的程度,以及 (3) 衡量技术转型的程度已通过变更。

You should note that there is no universal SPI framework. In fact, the SPI framework that is chosen by an organization reflects the people in the organization that are championing the SPI effort. As an SPI framework is applied, an organization must establish mechanisms to: (1) support technology transition, (2) determine the degree to which an organization is ready to absorb process changes that are proposed, and (3) measure the degree to which changes have been adopted.

28.1.2 成熟度模型

28.1.2 Maturity Models

成熟度模型应用于SPI 框架的上下文中。成熟度模型的目的是提供软件组织所表现出的“过程成熟度”的总体指标,即软件过程的质量、从业人员理解和应用过程的程度以及软件过程的质量的指标。软件工程实践的一般状况。这是使用某种类型的序数尺度来完成的。

A maturity model is applied within the context of an SPI framework. The intent of the maturity model is to provide an overall indication of the “process maturity” exhibited by a software organization, that is, an indication of the quality of the software process, the degree to which practitioners understand and apply the process, and the general state of software engineering practice. This is accomplished using some type of ordinal scale.

例如,软件工程研究所最初的能力成熟度模型第 28.3 节)提出了五个成熟度级别,从初始(基本软件过程)到优化(导致最佳实践的过程)。1第 571 页

For example, the Software Engineering Institute’s original Capability Maturity Model (Section 28.3) suggests five levels of maturity ranging from initial (rudimentary software process) to optimized (a process that leads to best practices).1Page 571

最重要的问题是成熟度衡量标准(例如作为能力成熟度模型集成(CMMI)流程框架的一部分提出的成熟度​​衡量标准)是否能提供任何真正的好处。我们认为他们确实如此。成熟度等级提供了易于理解的流程质量快照,从业者和管理者可以将其用作规划改进策略的基准。

The overriding question is whether maturity scales, such as the one proposed as part of the Capability Maturity Model Integration (CMMI) process framework, provide any real benefit. We think that they do. A maturity scale provides an easily understood snapshot of process quality that can be used by practitioners and managers as a benchmark from which improvement strategies can be planned.

28.1.3 SPI 适合所有人吗?

28.1.3 Is SPI for Everyone?

多年来,SPI 被视为一项“公司”活动——这是只有大公司才执行的活动的委婉说法。但如今,所有软件开发的很大一部分是由员工少于 100 人的公司(或者对于初创公司而言少于 24 人)进行的。小公司能否发起并成功开展 SPI 活动?

For many years, SPI was viewed as a “corporate” activity—a euphemism for something that only large companies perform. But today, a significant percentage of all software development is being performed by companies that employ fewer than 100 people (or in the case of startups less than 24 people). Can a small company initiate SPI activities and do it successfully?

大型软件开发组织和小型软件开发组织之间存在着巨大的文化差异。小型组织更加非正式,应用的标准实践较少,并且往往是自组织,这不足为奇。他们还倾向于为软件组织中各个成员的“创造力”感到自豪,并且最初认为 SPI 框架过于官僚和笨重。然而,流程改进对于小型组织和大型组织同样重要。

There are substantial cultural differences between large software development organizations and small ones. It should come as no surprise that small organizations are more informal, apply fewer standard practices, and tend to be self-organizing. They also tend to pride themselves on the “creativity” of individual members of the software organization, and initially view an SPI framework as overly bureaucratic and ponderous. Yet, process improvement is as important for a small organization as it is for a large one.

在小型组织内,实施 SPI 框架所需的资源可能会短缺。管理者必须分配人员和资金来实现软件工程。因此,无论软件组织的规模如何,考虑 SPI 的商业动机都是合理的。您始终需要查看所提议的流程活动。如果某个特定的流程模型或 SPI 方法感觉对您的组织来说有点大材小用,那么它可能确实如此。

Within small organizations the implementation of an SPI framework requires resources that may be in short supply. Managers must allocate people and money to make software engineering happen. Therefore, regardless of the size of the software organization, it’s reasonable to consider the business motivation for SPI. You always need to look at the process activities that are being proposed. If a specific process model or SPI approach feels like overkill for your organization, it probably is.

对许多项目的定量分析表明,小型组织青睐的敏捷项目方法可以提高流程效率并提高客户满意度[Ser15]。SPI 仍有可能只有在其支持者展示财务杠杆后才会获得批准和实施[Bir98]。财务杠杆通过检查技术收益(例如,减少交付现场的缺陷、减少返工、降低维护成本或加快上市时间)并将其转化为美元来证明。您必须展示现实的投资回报(第 28.6 节)以证明 SPI 成本的合理性。

Quantitative analyses of many projects have shown that the agile project methodologies favored by smaller organizations can lead to greater process efficiency and increase customer satisfaction [Ser15]. It is still likely SPI will be approved and implemented only after its proponents demonstrate financial leverage [Bir98]. Financial leverage is demonstrated by examining technical benefits (e.g., fewer defects delivered to the field, reduced rework, lower maintenance costs, or more rapid time to market) and translating them into dollars. You must show a realistic return on investment (Section 28.6) to justify SPI costs.

28.2 SPI过程

28.2 The SPI Process

SPI 的困难部分不是定义高质量软件流程的特征或创建流程成熟度模型。这些事情都比较容易。相反,困难的部分是为启动 SPI 建立共识并定义在整个软件组织中实施它的持续策略。

The hard part of SPI isn’t the definition of characteristics that define a high-quality software process or the creation of a process maturity model. Those things are relatively easy. Rather, the hard part is establishing a consensus for initiating SPI and defining an ongoing strategy for implementing it across a software organization.

软件工程学院开发了 IDEAL——“一种组织改进模型,可作为启动、规划和实施改进行动的路线图”[SEI08]。IDEAL 代表了 SPI 的许多流程模型,定义了五种不同的活动——启动、诊断、建立、行动和学习——指导组织完成 SPI 活动。第 572 页

The Software Engineering Institute has developed IDEAL—“an organizational improvement model that serves as a road map for initiating, planning, and implementing improvement actions” [SEI08]. IDEAL is representative of many process models for SPI, defining five distinct activities—initiating, diagnosing, establishing, acting, and learning—that guide an organization through SPI activities.Page 572

在本书中,我们基于 [Pre88] 中最初提出的 SPI 流程模型,提出了一个略有不同的 SPI 路线图。它应用了一种常识性哲学,要求组织 (1) 照照镜子,(2) 然后变得更加聪明,以便做出明智的选择,(3) 选择最能满足其需求的流程模型(和相关技术元素), (4) 将模型实例化到其操作环境和文化中,以及 (5) 评估已完成的工作。这五项活动(在接下来的第2小节中讨论)以迭代(循环)的方式应用,以促进持续的流程改进。

In this book, we present a somewhat different road map for SPI, based on the process model for SPI originally proposed in [Pre88]. It applies a commonsense philosophy that requires an organization to (1) look in the mirror, (2) then get smarter so it can make intelligent choices, (3) select the process model (and related technology elements) that best meets its needs, (4) instantiate the model into its operating environment and its culture, and (5) evaluate what has been done. These five activities (discussed in the subsections2 that follow) are applied in an iterative (cyclical) manner that fosters continuous process improvement.

28.2.1 评估和差距分析

28.2.1 Assessment and Gap Analysis

任何在不首先评估当前框架活动和相关软件工程实践的有效性的情况下改进当前软件流程的尝试都将像开始一段前往新地点的长途旅行,而不知道从哪里开始。你会兴高采烈地离开,四处闲逛,试图找到自己的方位,花费大量的精力,忍受大量的挫败感,很可能,你决定无论如何都不想旅行。简而言之,在开始任何旅程之前,最好准确地了解自己所在的位置。

Any attempt to improve your current software process without first assessing the efficacy of current framework activities and associated software engineering practices would be like starting on a long journey to a new location with no idea where you are starting from. You’d depart with great flourish, wander around trying to get your bearings, expend lots of energy and endure large doses of frustration, and likely, decide you really didn’t want to travel anyway. Stated simply, before you begin any journey, it’s a good idea to know precisely where you are.

第一个路线图活动称为评估,可让您了解方向。评估的目的是发现您的组织应用现有软件流程以及填充该流程的软件工程实践的方式的优点和缺点。

The first road map activity, called assessment, allows you to get your bearings. The intent of assessment is to uncover both strengths and weaknesses in the way your organization applies the existing software process and the software engineering practices that populate the process.

评估检查将导致高质量流程的各种行动和任务。例如,无论选择何种流程模型,软件组织都必须建立通用机制,例如定义的客户沟通方法;建立代表用户需求的方法;项目管理框架,包括范围界定、估算、日程安排和项目跟踪;风险分析方法;变更管理程序;质量保证和控制活动,包括审查;以及许多其他人。每个问题都在已建立的框架活动(第 2 章)的背景下进行考虑,并对每个问题进行评估以确定以下所有问题是否已得到解决:

Assessment examines a wide range of actions and tasks that will lead to a high-quality process. For example, regardless of the process model that is chosen, the software organization must establish generic mechanisms such as defined approaches for customer communication; established methods for representing user requirements; a project management framework that includes scoping, estimation, scheduling, and project tracking; risk analysis methods; change management procedures; quality assurance and control activities including reviews; and many others. Each is considered within the context of the framework activities (Chapter 2) that have been established, and each is assessed to determine whether all the following questions have been addressed:

  • 活动的目标是否明确?

  • Is the objective of the activity clearly defined?

  • 工作产品是否需要作为输入并作为输出被识别和描述而产生?

  • Are work products required as input and produced as output identified and described?

  • 是否清楚地描述了要执行的工作任务?

  • Are the work tasks to be performed clearly described?

  • 必须执行该活动的人员是否按角色确定?

  • Are the people who must perform the activity identified by role?

  • 是否制定了进入和退出标准?

  • Have entry and exit criteria been established?

  • 是否已建立活动指标?

  • Have metrics for the activity been established?

  • 是否有工具可以支持该活动?

  • Are tools available to support the activity?

  • 是否有针对该活动的明确培训计划?

  • Is there an explicit training program that addresses the activity?

  • 所有项目的活动是否统一执行?

  • Is the activity performed uniformly for all projects?

第 573 页尽管所提出的问题暗示是否的答案,但评估的作用是查看答案,以确定所讨论的活动是否以符合最佳实践的方式进行。

Page 573Although the questions noted imply a yes or no answer, the role of assessment is to look behind the answer to determine whether the activity in question is being performed in a manner that would conform to best practice.

在进行过程评估时,您(或受聘执行评估的人员)还应关注以下问题:

As the process assessment is conducted, you (or those who have been hired to perform the assessment) should also focus on the following issues:

一致性。所有软件项目和所有软件团队是否一致地应用重要的活动、行动和任务?

Consistency. Are important activities, actions, and tasks applied consistently across all software projects and by all software teams?

精致。管理和技术行动是否达到一定的复杂程度,意味着对最佳实践的透彻理解?

Sophistication. Are management and technical actions performed with a level of sophistication that implies a thorough understanding of best practice?

验收。软件过程和软件工程实践是否被管理和技术人员广泛接受?

Acceptance. Is the software process and software engineering practice widely accepted by management and technical staff?

承诺。管理层是否投入了实现一致性、复杂性和接受度所需的资源?

Commitment. Has management committed the resources required to achieve consistency, sophistication, and acceptance?

本地应用程序与最佳实践之间的差异代表了提供改进机会的“差距”。一致性、复杂性、接受度和承诺的实现程度表明了实现有意义的改进所需的文化变革的程度。

The difference between local application and best practice represents a “gap” that offers opportunities for improvement. The degree to which consistency, sophistication, acceptance, and commitment are achieved indicates the amount of cultural change that will be required to achieve meaningful improvement.

28.2.2 教育和培训

28.2.2 Education and Training

尽管很少有软件人员质疑敏捷、有组织的软件流程或可靠的软件工程实践的好处,但许多从业者和管理者对这两个问题都了解不够。3因此,在引入 SPI 框架时,对流程和实践的不准确认知会导致做出不适当的决策。由此可见,任何 SPI 战略的关键要素都是对从业者、技术经理以及与软件组织直接接触的高级管理人员进行教育和培训。明智的做法是尝试提供针对软件团队实际需求的“及时”培训。应开展三类教育和培训:通用软件工程概念和方法、特定技术和工具、以及以沟通和质量为导向的主题。在现代背景下,教育和培训可以通过多种不同的方式进行。从播客到 YouTube 短视频,再到更全面的基于互联网的培训(例如 Coursera、4)到电子书,再到课堂课程,一切都可以作为 SPI 战略的一部分提供。

Although few software people question the benefit of an agile, organized software process or solid software engineering practices, many practitioners and managers do not know enough about either subject.3 As a consequence, inaccurate perceptions of process and practice lead to inappropriate decisions when an SPI framework is introduced. It follows that a key element of any SPI strategy is education and training for practitioners, technical managers, and more senior managers who have direct contact with the software organization. It is wise to try to provide “just-in-time” training targeted to the real needs of a software team. Three types of education and training should be conducted: generic software engineering concepts and methods, specific technology and tools, and communication and quality-oriented topics. In a modern context, education and training can be delivered in a variety of different ways. Everything from podcasts, to short YouTube videos, to more comprehensive Internet-based training such as Coursera,4 to e-books, to classroom courses can be offered as part of an SPI strategy.

28.2.3 选择和理由

28.2.3 Selection and Justification

一旦初始评估活动5完成并且教育开始,软件组织就应该开始做出选择。这些选择发生在选择和论证活动期间,其中选择过程特征和特定的软件工程方法和工具来填充软件过程。

Once the initial assessment activity5 has been completed and education has begun, a software organization should begin to make choices. These choices occur during a selection and justification activity in which process characteristics and specific software engineering methods and tools are chosen to populate the software process.

第 574 页首先,您应该选择最适合您的组织、利益相关者以及您构建的软件的流程模型(第 2 章第 4章)。您应该决定将应用哪一组框架活动、将生成的主要工作产品以及使您的团队能够评估进度的质量保证检查点。如果 SPI 评估活动表明您有特定的弱点(例如,您没有正式的 SQA 职能),那么您应该将注意力集中在将直接解决这些弱点的流程特征上。

Page 574First, you should choose the process model (Chapters 2 through 4) that best fits your organization, its stakeholders, and the software that you build. You should decide which of the set of framework activities will be applied, the major work products that will be produced, and the quality assurance checkpoints that will enable your team to assess progress. If the SPI assessment activity indicates that you have specific weaknesses (e.g., you have no formal SQA functions), you should focus attention on process characteristics that will address these weaknesses directly.

接下来,为每个框架活动(例如建模)制定适应性工作分解,定义将应用于典型项目的任务集。您还应该考虑可用于完成这些任务的软件工程方法。在做出选择时,应协调教育和培训,以确保加深理解。

Next, develop an adaptable work breakdown for each framework activity (e.g., modeling), defining the task set that would be applied for a typical project. You should also consider the software engineering methods that can be applied to achieve these tasks. As choices are made, education and training should be coordinated to ensure that understanding is reinforced.

当您做出选择时,请务必考虑您组织的文化以及每个选择可能引起的接受程度。理想情况下,每个人共同努力选择各种流程和技术元素,并顺利进行安装或迁移活动(第 28.2.4 节)。事实上,选择之路可能崎岖不平。不同选民之间往往很难达成共识。如果选择标准是由委员会制定的,人们可能会无休止地争论标准是否合适,选择是否真正符合既定的标准。

As you make your choices, be sure to consider the culture of your organization and the level of acceptance that each choice will likely elicit. Ideally, everyone works together to select various process and technology elements and moves smoothly toward the installation or migration activity (Section 28.2.4). In reality, selection can be a rocky road. It is often difficult to achieve consensus among different constituencies. If the criteria for selection are established by committee, people may argue endlessly about whether the criteria are appropriate and whether a choice truly meets the criteria that have been established.

诚然,错误的选择弊大于利,但“分析瘫痪”意味着几乎没有任何进展,而且流程问题仍然存在。只要流程特征或技术元素有很好的机会满足组织的需求,有时最好扣动扳机并做出选择,而不是等待完美的解决方案。

It is true that a bad choice can do more harm than good, but “paralysis by analysis” means that little if any progress occurs and process problems remain. As long as the process characteristic or technology element has a good chance at meeting an organization’s needs, it’s sometimes better to pull the trigger and make a choice, rather than waiting for the perfect solution.

28.2.4 安装/迁移

28.2.4 Installation/Migration

安装是软件组织感受到遵循 SPI 路线图所触发的更改影响的第一个点。在某些情况下,建议组织采用全新的流程。框架活动、软件工程操作和单独的工作任务必须被定义并安装为新的软件工程文化的一部分。这些变化代表着重大的组织和技术转变,必须非常谨慎地管理。

Installation is the first point at which a software organization feels the effects of changes triggered by following the SPI road map. In some cases, an entirely new process is recommended for an organization. Framework activities, software engineering actions, and individual work tasks must be defined and installed as part of a new software engineering culture. Such changes represent a substantial organizational and technological transition and must be managed very carefully.

在其他情况下,与 SPI 相关的更改相对较小,表示对现有流程模型的微小但有意义的修改。此类更改通常称为进程迁移。如今,许多软件组织都有一个适当的“流程”。问题是它不能有效地发挥作用。因此,从一个流程(效果不如预期)增量迁移到另一个流程是一种更有效的策略。

In other cases, changes associated with SPI are relatively minor, representing small, but meaningful, modifications to an existing process model. Such changes are often referred to as process migration. Today, many software organizations have a “process” in place. The problem is that it doesn’t work in an effective manner. Therefore, an incremental migration from one process (that doesn’t work as well as desired) to another process is a more effective strategy.

安装和迁移是软件流程重新设计(SPR) 活动。Scacchi [Sca00] 指出,“SPR 关注的是新方法的识别、应用和改进,以显着改进和转变软件流程。” 当启动正式的 SPR 方法时,需要考虑三种不同的流程模型:(1) 现有(“现状”)流程,(2) 过渡(“从这里到那里”)流程,以及目标(“成为目标”) “) 过程。如果目标流程与现有流程显着不同,则唯一合理的安装方法是渐进策略,其中逐步实施过渡流程。过渡过程提供了一系列的路径点,使软件组织的文化能够适应随着时间的推移发生的微小变化。第 575 页

Installation and migration are software process redesign (SPR) activities. Scacchi [Sca00] states that “SPR is concerned with identification, application, and refinement of new ways to dramatically improve and transform software processes.” When a formal approach to SPR is initiated, three different process models are considered: (1) the existing (“as is”) process, (2) a transitional (“here to there”) process, and the target (“to be”) process. If the target process is significantly different from the existing process, the only rational approach to installation is an incremental strategy in which the transitional process is implemented in steps. The transitional process provides a series of waypoints that enable the software organization’s culture to adapt to small changes over time.Page 575

28.2.5 评估

28.2.5 Evaluation

尽管它被列为 SPI 路线图中的最后一项活动,但评估贯穿整个 SPI。评估活动评估变更被实例化和采用的程度、此类变更带来更好的软件质量或其他有形流程效益的程度,以及随着 SPI 活动的进行,流程和组织文化的总体状态。

Although it is listed as the last activity in the SPI road map, evaluation occurs throughout SPI. The evaluation activity assesses the degree to which changes have been instantiated and adopted, the degree to which such changes result in better software quality or other tangible process benefits, and the overall status of the process and the organizational culture as SPI activities proceed.

评估活动期间同时考虑定性因素和定量指标。从定性的角度来看,过去的管理层和从业者对软件流程的态度可以与安装流程变更后调查的态度进行比较。定量指标(第 23 章)是从使用过渡或“未来”流程的项目中收集的,并与为在“现状”流程下进行的项目收集的类似指标进行比较。

Both qualitative factors and quantitative metrics are considered during the evaluation activity. From a qualitative point of view, past management and practitioner attitudes about the software process can be compared to attitudes polled after installation of process changes. Quantitative metrics (Chapter 23) are collected from projects that have used the transitional or “to be” process and compared with similar metrics that were collected for projects that were conducted under the “as is” process.

28.2.6 SPI 风险管理

28.2.6 Risk Management for SPI

SPI 是一项有风险的事业。SPI 经常失败,因为没有正确考虑风险并且没有制定应急计划。事实上,超过一半的 SPI 努力都以失败告终。失败的原因多种多样,并且因组织而异。最常见的风险包括:缺乏管理支持、技术人员的文化抵制、计划不周的 SPI 战略、过于正式的 SPI 方法、选择不适当的流程、缺乏关键利益相关者的支持、预算、缺乏员工培训和组织不稳定,但还有许多其他因素。负责 SPI 的人员的职责是分析可能的风险并制定缓解风险的内部策略 [Dut15]。

SPI is a risky undertaking. SPI often fails because risks were not properly thought through and no contingency planning occurred. In fact, more than half of all SPI efforts end in failure. The reasons for failure vary greatly and are organizationally specific. Among the most common risks are: a lack of management support, cultural resistance by technical staff, a poorly planned SPI strategy, an overly formal approach to SPI, selection of an inappropriate process, a lack of buy-in by key stakeholders, an inadequate budget, a lack of staff training, and organizational instability, but there are a myriad of other factors. The role of those chartered with the responsibility for SPI is to analyze likely risks and develop an internal strategy for mitigating them [Dut15].

软件组织应在 SPI 流程中的三个关键点管理风险 [Ive04]:在 SPI 路线图启动之前、在 SPI 活动执行期间(评估、教育、选择、安装)以及在评估活动期间遵循某些流程特征的实例化。一般来说,SPI 风险因素可以分为以下几类 [Ive04]:预算和成本、内容和可交付成果、文化、SPI 可交付成果的维护、使命和目标、组织管理、组织稳定性、流程利益相关者、SPI 开发时间表、 SPI开发环境、SPI开发流程、SPI项目管理和SPI人员。

A software organization should manage risk at three key points in the SPI process [Ive04]: prior to the initiation of the SPI road map, during the execution of SPI activities (assessment, education, selection, installation), and during the evaluation activity that follows the instantiation of some process characteristic. In general, the following categories [Ive04] can be identified for SPI risk factors: budget and cost, content and deliverables, culture, maintenance of SPI deliverables, mission and goals, organizational management, organizational stability, process stakeholders, schedule for SPI development, SPI development environment, SPI development process, SPI project management, and SPI staff.

在每个类别中,可以识别几个通用风险因素。例如,组织文化对风险有很大影响。可以为文化类别 [Ive04] 定义以下通用风险因素6 :

Within each category, several generic risk factors can be identified. For example, the organizational culture has a strong bearing on risk. The following generic risk factors6 can be defined for the culture category [Ive04]:

  • 对改变的态度,基于之前的改变努力

  • Attitude toward change, based on prior efforts to change

  • 优质项目的经验、成功程度

  • Experience with quality programs, level of success

  • 解决问题的行动导向与政治斗争

  • Action orientation for solving problems versus political struggles

  • 使用事实来管理组织和业务

  • Use of facts to manage the organization and business

  • 第 576 页对变化有耐心;花时间社交的能力

  • Page 576Patience with change; ability to spend time socializing

  • 工具导向——期望工具能解决问题

  • Tools orientation—expectation that tools can solve the problems

  • “计划性”水平——组织计划的能力

  • Level of “planfulness”—ability of organization to plan

  • 组织成员公开参与各级组织会议的能力

  • Ability of organization members to participate with various levels of organization openly at meetings

  • 组织成员有效管理会议的能力

  • Ability of organization members to manage meetings effectively

  • 具有已定义流程的组织的经验水平

  • Level of experience in organization with defined processes

使用风险因素和通用属性作为指导,可以开发风险表(第 26 章)来隔离那些需要管理层进一步关注的风险。

Using the risk factors and generic attributes as a guide, a risk table (Chapter 26) can be developed to isolate those risks that warrant further management attention.

28.3 CMMI

28.3 The CMMI

最初的能力成熟度模型 CMM)是由软件工程研究所在整个 90 年代开发和升级为完整的 SPI 框架。如今,它已发展成为能力成熟度模型集成(CMMI) [CMM18],这是一个综合的流程元模型,基于一组系统和软件工程能力,当组织达到不同级别的流程能力和成熟度时,应呈现这些能力。

The original Capability Maturity Model (CMM) was developed and upgraded by the Software Engineering Institute throughout the 1990s as a complete SPI framework. Today, it has evolved into the Capability Maturity Model Integration (CMMI) [CMM18], a comprehensive process meta-model that is predicated on a set of system and software engineering capabilities that should be present as organizations reach different levels of process capability and maturity.

CMMI 以两种不同的方式表示流程元模型:(1) 作为“连续”模型和 (2) 作为“分阶段”模型。连续 CMMI 元模型描述了二维过程,如图28.2所示。每个过程领域(例如,项目规划或需求管理)都根据特定目标和实践进行正式评估,并根据以下能力级别进行评级:

The CMMI represents a process meta-model in two different ways: (1) as a “continuous” model and (2) as a “staged” model. The continuous CMMI meta-model describes a process in two dimensions as illustrated in Figure 28.2. Each process area (e.g., project planning or requirements management) is formally assessed against specific goals and practices and is rated according to the following capability levels:

图28.2 CMMI 过程域能力概况

Figure 28.2 CMMI process area capability profile

来源:Phillips, Mike,“CMMI V1.1 教程”,2002 年 4 月 9 日。

Source: Phillips, Mike, “CMMI V1.1 Tutorial,” April 9, 2002.

  • 0级:不完整过程域(例如,需求管理)要么没有执行,要么没有实现 CMMI 为过程域的 1 级能力定义的所有目的和目标。

  • Level 0: Incomplete. The process area (e.g., requirements management) is either not performed or does not achieve all goals and objectives defined by the CMMI for level 1 capability for the process area.

  • 第 577 页1 级:已执行过程域的所有具体目标(由 CMMI 定义)均已满足。正在执行生成定义的工作产品所需的工作任务。

  • Page 577Level 1: Performed. All the specific goals of the process area (as defined by the CMMI) have been satisfied. Work tasks required to produce defined work products are being conducted.

  • 2 级:托管所有能力级别 1 标准均已满足。此外,与过程域相关的所有工作都符合组织定义的策略;所有从事这项工作的人都可以获得足够的资源来完成工作;利益相关者根据需要积极参与过程域;所有工作任务和工作产品都受到“监视、控制和审查”;并评估是否遵守流程描述”[CMM18]。

  • Level 2: Managed. All capability level 1 criteria have been satisfied. In addition, all work associated with the process area conforms to an organizationally defined policy; all people doing the work have access to adequate resources to get the job done; stakeholders are actively involved in the process area as required; all work tasks and work products are “monitored, controlled, and reviewed; and are evaluated for adherence to the process description” [CMM18].

  • 级别 3:已定义所有能力 2 级标准均已达到。此外,该流程“根据组织的定制指南从组织的标准流程集进行定制,并向组织流程资产贡献工作产品、措施和其他流程改进信息”[CMM18]。

  • Level 3: Defined. All capability level 2 criteria have been achieved. In addition, the process is “tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines, and contributes work products, measures, and other process-improvement information to the organizational process assets” [CMM18].

  • 第四级:量化管理所有能力 3 级标准均已达到。此外,通过测量和定量评估来控制和改进过程区域。“建立质量和过程绩效的定量目标并将其用作管理过程的标准”[CMM18]。

  • Level 4: Quantitatively managed. All capability level 3 criteria have been achieved. In addition, the process area is controlled and improved using measurement and quantitative assessment. “Quantitative objectives for quality and process performance are established and used as criteria in managing the process” [CMM18].

  • 5级:优化所有能力 4 级标准均已达到。此外,使用定量(统计)手段对过程区域进行调整和优化,以满足不断变化的客户需求并不断提高所考虑的过程区域的效率。

  • Level 5: Optimized. All capability level 4 criteria have been achieved. In addition, the process area is adapted and optimized using quantitative (statistical) means to meet changing customer needs and to continually improve the efficacy of the process area under consideration.

CMMI 根据“具体目标”和实现这些目标所需的“具体实践”来定义每个过程域。如果过程域所隐含的活动要有效,则特定目标确定了必须存在的特征。具体实践将目标细化为一组与流程相关的活动。

The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific practices refine a goal into a set of process-related activities.

除了特定的目标和实践之外,CMMI 还为每个过程域定义了一组五个通用目标和相关实践。五个通用目标中的每一个都对应于五个能力级别之一。为了达到成熟度级别,必须实现与一组过程域相关的特定目标和实践。成熟度级别和过程域之间的关系如图28.3所示。

In addition to specific goals and practices, the CMMI also defines a set of five generic goals and related practices for each process area. Each of the five generic goals corresponds to one of the five capability levels. To achieve a maturity level, the specific goals and practices associated with a set of process areas must be achieved. The relationship between maturity levels and process areas is shown in Figure 28.3.

图28.3 达到成熟度级别所需的过程

Figure 28.3 Process areas required to achieve a maturity level

一个软件过程,无论构思得多么好,如果没有才华横溢、积极进取的软件人员,就不会成功。人员CMM建议提高员工能力和文化的实践 [CMM18a]。人员 CMM 的目标是鼓励持续改进通用劳动力知识(称为“核心能力”)、特定软件工程和项目管理技能(称为“劳动力能力”)以及流程相关能力。与 CMMI 一样,人员 CMM 定义了一组五个组织成熟度级别,这些级别提供了劳动力实践和流程的相对复杂程度的指示。第 578 页

A software process, no matter how well conceived, will not succeed without talented, motivated software people. The People CMM suggests practices that improve the workforce competence and culture [CMM18a]. The goal of the People CMM is to encourage continuous improvement of generic workforce knowledge (called “core competencies”), specific software engineering and project management skills (called “workforce competencies”), and process-related abilities. Like the CMMI, the People CMM defines a set of five organizational maturity levels that provide an indication of the relative sophistication of workforce practices and processes.Page 578

28.4 其他SPI框架

28.4 Other SPI Frameworks

尽管SEI 的CMM 和CMMI 是应用最广泛的SPI 框架,但已经提出并正在使用几种替代方案7 7 。我们简要概述了其中两个框架。8

Although the SEI’s CMM and CMMI are the most widely applied SPI frameworks, several alternatives7 have been proposed and are in use. We provide a brief overview of two of these frameworks.8

28.4.1 香料

28.4.1 SPICE

SPICE(软件过程改进和能力测定)模型 [SPI99] 提供了符合 ISO 15504-5:2015 和 ISO 12207:2017 的 SPI 评估框架。SPICE 的目的是提供一个框架来评估流程并提供有关优势、劣势和能力的信息,以帮助组织实现其目标。[Kar12l 概述了 SPI 框架,包括流程管理模型、进行评估的指南以及对正在考虑的流程进行评级。

The SPICE (Software Process Improvement and Capability dEtermination) model [SPI99] provides an SPI assessment framework that is compliant with ISO 15504-5:2015 and ISO 12207:2017. The purpose of SPICE was to provide a framework to assess a process and provide information on the strengths, weaknesses, and capabilities to help an organization achieve its goals. [Kar12l presents an overview of the SPI framework, including a model for process management, guidelines for conducting an assessment, and rating the process under consideration.

28.4.2 TickIT 加

28.4.2 TickIT Plus

TickIT 审核方法 [Tic18] 确保软件符合 ISO 9001:2015 这是一个通用标准,适用于任何想要提高其提供的产品、系统或服务整体质量的组织。因此,该标准直接适用于软件组织和公司。

The TickIT auditing method [Tic18] ensures compliance with ISO 9001:2015 for Softwarea generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies.

ISO 9001:2015 采用了“计划-实施-检查-行动”循环,应用于软件项目的质量管理要素。在软件环境中,“计划”建立了实现高质量软件和最终客户满意度所需的过程目标、活动和任务。“Do”实施软件流程(包括框架和伞式活动)。“行动”启动软件过程改进活动,不断努力改进过程。TickIT 可在整个“计划-执行-检查-行动”周期中使用,以确保 SPI 取得进展。TickIT 审核员评估该周期的应用情况,作为 ISO 9001:2015 认证的先导。有关 ISO 9001:2015 和 TickIT 的详细讨论,您应该查看 [Tic18] 和 [ISO15]。

ISO 9001:2015 has adopted a “plan-do-check-act” cycle that is applied to the quality management elements of a software project. Within a software context, “plan” establishes the process objectives, activities, and tasks necessary to achieve high-quality software and resultant customer satisfaction. “Do” implements the software process (including both framework and umbrella activities). “Act” initiates software process improvement activities that continually work to improve the process. TickIT can be used throughout the “plan-do-check-act” cycle to ensure that SPI progress is being made. TickIT auditors assess the application of the cycle as a precursor to ISO 9001:2015 certification. For a detailed discussion of ISO 9001:2015 and TickIT, you should examine [Tic18] and [ISO15].

第 580 页

Page 580

28.5 SPI 投资回报

28.5 SPI Return on Investment

SPI是一项艰苦的工作,需要大量的资金和人力投入。批准 SPI 预算和资源的管理者总是会问这样的问题:“我怎么知道我们所花的钱会获得合理的回报?”

SPI is hard work and requires substantial investment of dollars and people. Managers who approve the budget and resources for SPI will invariably ask the question: “How do I know that we’ll achieve a reasonable return for the money we’re spending?”

在定性层面上,SPI 的支持者认为改进的软件流程将提高软件质量。他们认为,改进的流程将导致实施更高质量的过滤器(从而减少传播的缺陷)、更好地控制变更(从而减少项目混乱)以及更少的技术返工(从而降低成本并缩短上市时间) )。但这些定性效益能否转化为定量结果?经典的投资回报 (ROI) 方程是:

At a qualitative level, proponents of SPI argue that an improved software process will lead to improved software quality. They contend that an improved process will result in the implementation of better-quality filters (resulting in fewer propagated defects), better control of change (resulting in less project chaos), and less technical rework (resulting in lower cost and better time to market). But can these qualitative benefits be translated into quantitative results? The classic return on investment (ROI) equation is:

在哪里

where

好处包括与更高的产品质量(更少的缺陷)相关的成本节约、更少的返工、减少与变更相关的工作量以及因更短的上市时间而产生的收入。

benefits include the cost savings associated with higher product quality (fewer defects), less rework, reduced effort associated with changes, and the income that accrues from shorter time to market.

成本包括直接 SPI 成本(例如,培训、测量)和与更加重视质量控制和变更管理活动以及更严格地应用软件工程方法(例如,创建设计模型)相关的间接成本。

costs include both direct SPI costs (e.g., training, measurement) and indirect costs associated with greater emphasis on quality control and change management activities and more rigorous application of software engineering methods (e.g., the creation of a design model).

在现实世界中,这些定量的收益和成本有时很难准确衡量,而且都可以解释。但这并不意味着软件组织应该在不仔细分析由此产生的成本和收益的情况下实施 SPI 计划。即使非常小的软件组织也能从软件流程改进中受益,但他们会检查他们选择采用的 SPI 活动的投资回报率 [Lar16]。David Rico [Ric04] 在一本独特的书中可以找到 SPI ROI 的综合处理。

In the real world, these quantitative benefits and costs are sometimes difficult to measure with accuracy, and all are open to interpretation. But that doesn’t mean that a software organization should conduct an SPI program without careful analysis of the costs and benefits that accrue. Even very small software organizations benefit from software process improvement, but they examine the ROI of the SPI activities they choose to employ [Lar16]. A comprehensive treatment of ROI for SPI can be found in a unique book by David Rico [Ric04].

28.6 SPI趋势

28.6 SPI Trends

在过去的 35 年里,许多公司尝试通过应用 SPI 框架来改进其软件工程实践,以实现组织变革和技术转型。正如我们在本章前面提到的,超过一半的人在这一努力中失败了。无论成功还是失败,都需要花费大量金钱。David Rico [Ric04] 报告称,SEI CMMI 等 SPI 框架的典型应用每人的成本可能在 25,000 美元到 70,000 美元之间,并且需要数年时间才能完成!毫不奇怪,SPI 的未来应该强调成本更低、耗时更短的方法。

Over the past 35 years, many companies have attempted to improve their software engineering practices by applying an SPI framework to effect organizational change and technology transition. As we noted earlier in this chapter, over half fail in this endeavor. Regardless of success or failure, all spend significant amounts of money. David Rico [Ric04] reports that a typical application of an SPI framework such as the SEI CMMI can cost between $25,000 and $70,000 per person and take years to complete! It should come as no surprise that the future of SPI should emphasize a less costly and time-consuming approach.

为了在二十一世纪的软件开发世界中发挥作用,未来的 SPI 框架必须变得更加敏捷 [Bjø16]。当代 SPI 工作应该集中在项目层面,而不是组织重点(可能需要数年才能成功完成),在几周内而不是几个月或几年内改进团队流程 [Bjø16]。为了在短时间内取得有意义的结果(即使在项目级别),复杂的框架模型可能会让位于更简单的模型 [Lar16]。敏捷 SPI 框架不应强调数十个关键实践和数百个补充实践,而应仅强调几个关键实践(例如,类似于本书中讨论的框架活动)[Din16]。第581页

To be effective in the twenty-first-century world of software development, future SPI frameworks must become significantly more agile [Bjø16]. Rather than an organizational focus (which can take years to complete successfully), contemporary SPI efforts should focus on the project level, working to improve a team process in weeks, not months or years [Bjø16]. To achieve meaningful results (even at the project level) in a short time frame, complex framework models may give way to simpler models [Lar16]. Rather than dozens of key practices and hundreds of supplementary practices, an agile SPI framework should emphasize only a few pivotal practices (e.g., analogous to the framework activities discussed throughout this book) [Din16].Page 581

SPI 的任何尝试都需要知识渊博的员工队伍,但教育和培训可能成本高昂,应尽量减少(并简化)。未来的 SPI 工作应该依赖于针对关键实践的基于网络的培训,而不是课堂课程(昂贵且耗时)。文化变革应该像现实世界中那样发生,一次一小群,直到达到临界点,而不是进行深远的尝试来改变组织文化(随之而来的所有政治危险)。Jovanovic 和他的同事建议使用回顾游戏作为 Scrum 回顾的一部分,作为教育和吸引敏捷开发团队成员参与流程改进的一种手段 [Jov15]。

Any attempt at SPI demands a knowledgeable workforce, but education and training can be expensive and should be minimized (and streamlined). Rather than classroom courses (expensive and time consuming), future SPI efforts should rely on Web-based training that is targeted at pivotal practices. Rather than far-reaching attempts to change organizational culture (with all the political perils that ensue), cultural change should occur as it does in the real world, one small group at a time until a tipping point is reached. Jovanovic and his colleagues suggest using retrospective gaming as part of the Scrum retrospective as a means of educating and engaging agile development team members in process improvement [Jov15].

过去三十年的 SPI 工作具有重大价值。已开发的框架和模型代表了软件工程社区的大量知识资产。但与所有事物一样,这些资产不是通过成为反复出现的教条来指导 SPI 的未来尝试,而是作为更好、更简单和更敏捷的 SPI 模型的基础。

The SPI work of the past three decades has significant merit. The frameworks and models that have been developed represent substantial intellectual assets for the software engineering community. But like all things, these assets guide future attempts at SPI not by becoming a recurring dogma, but by serving as the basis for better, simpler, and more agile SPI models.

28.7 总结

28.7 Summary

软件过程改进框架定义了要实现有效的软件过程必须具备的特征、帮助确定这些特征是否存在的评估方法以及帮助软件组织实现已实现的那些过程特征的策略。发现薄弱或缺失。无论组织中谁发起 SPI,目标都是提高流程质量并提高软件质量和及时性。

A software process improvement framework defines the characteristics that must be present if an effective software process is to be achieved, an assessment method that helps determine whether those characteristics are present, and a strategy for assisting a software organization in implementing those process characteristics that have been found to be weak or missing. Regardless of who in the organization sponsors SPI, the goal is to improve process quality and to improve software quality and timeliness.

流程成熟度模型提供了软件组织所表现出的“流程成熟度”的总体指示。它提供了对当前正在使用的软件流程的相对有效性的定性感受。

A process maturity model provides an overall indication of the “process maturity” exhibited by a software organization. It provides a qualitative feel for the relative effectiveness of the software process that is currently being used.

SPI 路线图从评估开始——一系列评估活动,揭示您的组织应用现有软件流程和填充该流程的软件工程实践方式的优势和劣势。评估是允许软件组织制定总体 SPI 计划的工具。

The SPI road map begins with assessment—a series of evaluation activities that uncover both strengths and weaknesses in the way your organization applies the existing software process and the software engineering practices that populate the process. Assessment is the tool that allows a software organization to develop an overall SPI plan.

任何 SPI 计划的关键要素之一是教育和培训,这项活动的重点是提高管理人员和从业人员的知识水平。一旦员工精通当前的软件技术,选择和论证就开始了。这些任务导致对软件过程的架构、填充它的方法以及支持它的工具的选择。安装和评估是 SPI 活动,用于实例化流程变更并评估其功效和影响。

One of the key elements of any SPI plan is education and training, an activity that focuses on improving the knowledge level of managers and practitioners. Once staff becomes well versed in current software technologies, selection and justification commence. These tasks lead to choices about the architecture of the software process, the methods that populate it, and the tools that support it. Installation and evaluation are SPI activities that instantiate process changes and assess their efficacy and impact.

为了成功改进其软件流程,组织必须表现出以下特征:管理层对 SPI 的承诺和支持、员工参与整个 SPI 流程、流程融入整体组织文化、针对本地需求定制的 SPI 策略以及可靠的 SPI 流程。 SPI 项目的管理。

To successfully improve its software process, an organization must exhibit the following characteristics: management commitment and support for SPI, staff involvement throughout the SPI process, process integration into the overall organizational culture, an SPI strategy that has been customized for local needs, and solid management of the SPI project.

第582页目前有多种 SPI 框架在使用。SEI的CMM和CMMI被广泛使用。人员 CMM 已经过定制,用于评估组织文化及其员工的质量。SPICE 和 TickIT 是可以实现有效 SPI 的附加框架。

Page 582Several SPI frameworks are in use today. The SEI’s CMM and CMMI are widely used. The People CMM has been customized to assess the quality of the organizational culture and the people who populate it. SPICE and TickIT are additional frameworks that can lead to effective SPI.

SPI 是一项艰苦的工作,需要大量的资金和人力投入。为了确保获得合理的投资回报,组织必须衡量与 SPI 相关的成本以及可直接归因于它的收益。

SPI is hard work that requires substantial investment of dollars and people. To ensure that a reasonable return on investment is achieved, an organization must measure the costs associated with SPI and the benefits that can be directly attributed to it.

问题与思考点

Problems and Points to Ponder

28.1。为什么软件组织在着手改进本地软件流程时常常陷入困境?

28.1. Why is it that software organizations often struggle when they embark on an effort to improve local software process?

28.2. 用你自己的话描述“流程成熟度”的概念。

28.2. Describe the concept of “process maturity” in your own words.

28.3。做一些研究(查看 SEI 网站),并确定美国和全球软件组织的流程成熟度分布。

28.3. Do some research (check the SEI website), and determine the process maturity distribution for software organizations in the United States and worldwide.

28.4。您在一家非常小的软件组织工作 — 只有 11 个人参与软件开发。SPI 适合您吗?解释你的答案。

28.4. You work for a very small software organization—only 11 people are involved in developing software. Is SPI for you? Explain your answer.

28.5。评估类似于年度体检。使用体检作为比喻,描述 SPI 评估活动。

28.5. Assessment is analogous to an annual physical exam. Using a physical exam as a metaphor, describe the SPI assessment activity.

28.6。“现状”流程、“从这里到那里”流程和“未来”流程之间有什么区别?

28.6. What is the difference between an “as is” process, a “here to there” process, and a “to be” process?

28.7。如何在 SPI 背景下应用风险管理?

28.7. How is risk management applied within the context of SPI?

28.8。对预测软件过程改进工作成功的关键因素进行一些研究。选择其中一个,然后写一篇论文,描述如何在小型软件开发组织中实现它。

28.8. Do some research on the key factors for predicting success in software process improvement efforts. Pick one of them, and write a paper describing how it might be achieved in a small software development organization.

28.9。进行一些研究,尝试确定如何将 CMMI 与敏捷流程框架结合使用。

28.9. Do some research to try to determine how CMMI can be used with agile process frameworks.

28.10。选择第 28.5 节中讨论的 SPI 框架之一,并写一篇简短的论文更详细地描述它。

28.10. Select one of the SPI frameworks discussed in Section 28.5, and write a brief paper describing it in more detail.

1原始 CMM 已更新并在第 28.3 节中讨论。

1 The original CMM has been updated and is discussed in Section 28.3.

2这些章节中的部分内容经许可改编自[Pre88]。

2 Some of the content in these sections has been adapted from [Pre88] with permission.

3如果你花时间读过这本书,你就不会成为他们中的一员!

3 If you’ve spent time reading this book, you won’t be one of them!

4请参阅 https://www.coursera.org/。

4 See https://www.coursera.org/.

5事实上,评估是一项持续的活动。它定期进行,旨在确定 SPI 战略是否实现了其近期目标,并为未来的改进奠定了基础。

5 In actuality, assessment is an ongoing activity. It is conducted periodically in an effort to determine whether the SPI strategy has achieved its immediate goals and to set the stage for future improvement.

6本节中提到的每个风险类别的风险因素可在 [Ive04] 中找到。

6 Risk factors for each of the risk categories noted in this section can be found in [Ive04].

7可以合理地认为,其中一些框架与其说是“替代品”,不如说它们是 SPI 的补充方法。有关更多 SPI 框架的综合表,请访问 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.4787&rep=rep1&type=pdf。

7 It’s reasonable to argue that some of these frameworks are not so much “alternatives” as they are complementary approaches to SPI. A comprehensive table of many more SPI frameworks can be found at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.4787&rep=rep1&type=pdf.

8如果您有进一步的兴趣,可以使用各种印刷版和基于 Web 的资源。

8 If you have further interest, a wide array of print and Web-based resources is available for each.

第583页

Page 583

章节

chapter

29软件工程的新兴趋势

29 Emerging Trends in Software Engineering

在软件工程相对较短的历史中,从业者和研究人员开发了一系列过程模型、技术方法和自动化工具,以努力促进我们构建计算机软件的方式发生根本性变化。尽管过去的经验表明情况并非如此,但人们还是有一种心照不宣的愿望,那就是找到“银弹”——神奇的过程或卓越的技术,使我们能够轻松地构建大型、复杂、基于软件的系统,而不会造成混乱、错误和延迟。 ——没有许多继续困扰软件工作的问题。

Throughout the relatively brief history of software engineering, practitioners and researchers have developed an array of process models, technical methods, and automated tools in an effort to foster fundamental change in the way we build computer software. Even though past experience indicates otherwise, there is a tacit desire to find the “silver bullet”—the magic process or transcendent technology that will allow us to build large, complex, software-based systems easily, without confusion, without mistakes, without delay—without the many problems that continue to plague software work.

第584页但历史表明,我们对灵丹妙药的追求似乎注定要失败。新技术定期被引入,被宣传为软件工程师面临的许多问题的“解决方案”,并被纳入大大小小的项目中。行业专家强调这些“新”软件技术的重要性,软件界的行家热情地采用它们,最终它们确实在软件工程世界中发挥了作用。但他们往往不会兑现自己的承诺,因此,探索仍在继续。

Page 584But history indicates that our quest for the silver bullet appears doomed to failure. New technologies are introduced regularly, hyped as “solutions” to many of the problems software engineers face, and incorporated into projects large and small. Industry pundits stress the importance of these “new” software technologies, the cognoscenti of the software community adopt them with enthusiasm, and ultimately, they do play a role in the software engineering world. But they tend not to meet their promise, and as a consequence, the quest continues.

在本书的过去版本(接近四十年)中,我们讨论了新兴技术及其对软件工程的预计影响。其中一些已被广泛采用,但另一些则从未发挥出其潜力。我们的结论是:技术来来去去;我们应该探索的真正趋势是更加柔和的。我们的意思是,软件工程的进步将受到业务、组织、市场和文化趋势的指导。这些趋势导致了技术创新。

In past editions of this book (approaching four decades), we have discussed emerging technologies and their projected impact on software engineering. Some have been widely adopted, but others never reached their potential. Our conclusion: Technologies come and go; the real trends that we should explore are softer. By this we mean that progress in software engineering will be guided by business, organizational, market, and cultural trends. Those trends lead to technology innovation.

在本章中,我们将提到一些软件工程技术趋势,但我们的主要重点将是一些可能在未来 10 或 20 年对软件工程技术产生重要影响的业务、组织、市场和文化趋势。年。

In this chapter, we’ll mention a few software engineering technology trends, but our primary emphasis will be on some of the business, organizational, market, and cultural trends that may have an important influence on software engineering technology over the next 10 or 20 years.

29.1 技术演进

29.1 Technology Evolution

Ray Kurzweil [Kur05] 在一本引人入胜的书中对计算(和其他相关)技术如何发展进行了引人注目的阐述,他认为技术进化与生物进化类似,但速度要快几个数量级。进化(无论是生物的还是技术的)是由于正反馈而发生的——“进化进步的一个阶段产生的更有能力的方法被用来创造下一阶段”[Kur05]。

In a fascinating book that provides a compelling look at how computing (and other related) technologies will evolve, Ray Kurzweil [Kur05] argued that technological evolution is similar to biological evolution, but at a rate that is orders of magnitude faster. Evolution (whether biological or technological) occurs as a result of positive feedback—“the more capable methods resulting from one stage of evolutionary progress are used to create the next stage” [Kur05].

二十一世纪的重大问题是:(1)技术发展的速度有多快?(2)正反馈的效果有多显着?(3) 由此产生的变化会有多深刻?

The big questions for the twenty-first century are: (1) How rapidly does a technology evolve? (2) How significant are the effects of positive feedback? (3) How profound will the resultant changes be?

当一项成功的新技术被引入时,最初的概念会经历一个可合理预测的“创新生命周期”[Gai95],如图29.1所示。在突破阶段,认识到问题并反复尝试可行的解决方案。在某些时候,解决方案会显示出希望。最初的突破性工作在复制器阶段被复制并获得更广泛的使用。经验主义导致了管理技术使用的经验规则的创建,而反复的成功导致了更广泛的使用理论,随后在自动化阶段创建了自动化工具。最终,技术成熟并得到广泛应用。第585页

When a successful new technology is introduced, the initial concept moves through a reasonably predictable “innovation life cycle” [Gai95], as illustrated in Figure 29.1. In the breakthrough phase, a problem is recognized and repeated attempts at a viable solution are attempted. At some point, a solution shows promise. The initial breakthrough work is reproduced in the replicator phase and gains wider usage. Empiricism leads to the creation of empirical rules that govern the use of the technology, and repeated success leads to a broader theory of usage that is followed by the creation of automated tools during the automation phase. Finally, the technology matures and is used widely.Page 585

29.1 技术创新周期

Figure 29.1 A technology innovation cycle

您应该注意到,许多研究和技术趋势从未达到成熟。事实上,软件工程领域中绝大多数“有前途”的技术在几年内都受到了广泛的关注,然后就被一群专门的追随者纳入了利基用途。这并不是说这些技术缺乏优点,而是强调创新生命周期的旅程漫长而艰难。

You should note that many research and technology trends never reach maturity. In fact, the vast majority of “promising” technologies in the software engineering domain receive widespread interest for a few years and then fall into niche usage by a dedicated band of adherents. This is not to say that these technologies lack merit, but rather to emphasize that the journey through the innovation life cycle is long and hard.

计算技术正在以指数速度发展,其增长可能很快就会呈爆炸性增长。Kurzweil [Kur05] 同意计算技术通过“S 曲线”发展,该曲线在技术形成时期表现出相对缓慢的增长,在其成长期快速加速,然后在技术达到极限时呈现平稳期。今天,我们正处于现代计算技术 S 曲线的拐点——处于早期增长和随后爆炸性增长之间的过渡期。这意味着,在未来 20 到 40 年里,我们将看到计算能力发生巨大(甚至令人难以置信)的变化。他认为,在 20 年内,技术进化将以越来越快的速度加速,最终导致非生物智能的时代,它将以令人着迷的方式与人类智能融合并扩展。

Computing technology is evolving at an exponential rate, and its growth may soon become explosive. Kurzweil [Kur05] agrees that computing technologies evolve through an “S-curve” that exhibits relatively slow growth during the technology’s formative years, rapid acceleration during its growth period, and then a leveling-off period as the technology reaches its limits. Today, we are at the knee of the S-curve for modern computing technologies—at the transition between early growth and the explosive growth that is to follow. The implication is that over the next 20 to 40 years, we will see dramatic (even mindboggling) changes in computing capability. He suggests that within 20 years, technology evolution will accelerate at an increasingly rapid pace, ultimately leading to an era of nonbiological intelligence that will merge with and extend human intelligence in ways that are fascinating to contemplate.

所有这一切,无论如何发展,都需要软件和系统,相比之下,我们目前的努力显得幼稚。到 2040 年,极限计算、人工智能和机器学习、纳米技术、大规模高带宽普适网络和机器人技术的结合将带领我们进入一个不同的世界。1软件——可能以我们尚无法理解的形式——将继续占据这个新世界的核心。软件工程不会消失。

And all of this, no matter how it evolves, will require software and systems that make our current efforts look infantile by comparison. By the year 2040, a combination of extreme computation, artificial intelligence and machine learning, nanotechnology, massively high bandwidth ubiquitous networks, and robotics will lead us into a different world.1 Software—possibly in forms we cannot yet comprehend—will continue to reside at the core of this new world. Software engineering will not go away.

29.2 软件工程作为一门学科

29.2 Software Engineering as a Discipline

近 50 年来,许多学术研究人员和行业专业人士一直呼吁建立真正的软件工程学科。在 1990 年关于该主题的经典论文的重要后续文章中,Mary Shaw [Sha09] 对这一持续探索做出了评论:

For almost 50 years, many academic researchers and industry professionals have clamored for a true engineering discipline for software. In an important follow-on to her classic 1990 paper on the subject, Mary Shaw [Sha09] comments on this continuing quest:

工程学科通常是从技术的工艺实践发展而来,足以供本地或临时使用。当该技术变得具有经济意义时,就需要稳定的生产技术和管理控制。由此产生的商业市场是基于经验,而不是对技术的深刻理解。。。当 时,工程职业就出现了。。。科学变得足够成熟,可以支持有目的的实践和设计演变,并产生可预测的结果。

Engineering disciplines typically evolve from craft practices of a technology, sufficient for local or ad hoc use. When the technology becomes economically significant, it requires stable production techniques and management control. The resulting commercial market is based on experience, rather than a deep understanding of the technology . . . an engineering profession emerges when . . . science becomes sufficiently mature to support purposeful practice and design evolution with predictable outcomes.

第586页我们认为,该行业已经实现了“有目的的实践”,但“可预测的结果”仍然难以捉摸。

Page 586We would argue that the industry has achieved “purposeful practice,” but that “predictable outcomes” have remained elusive.

随着移动性开始在软件领域占据主导地位,Shaw 发现了“非常复杂的系统及其用户之间的深层相互依赖关系所带来的挑战”[Sha09]。她认为,导致“有目的的实践”的知识库已经被现在遍布网络的专业社交网络民主化。例如,软件开发人员可以在适当的论坛上提出问题,并从许多其他开发人员的经验中获得众包解决方案,而不是参考集中控制的软件工程手册。所提出的解决方案经常受到实时批评,并提供替代方案和适应方案作为选项。

As mobility begins to dominate the software landscape, Shaw identifies challenges that “emerge from the deep interdependencies between very complex systems and their users” [Sha09]. She argues that the knowledge base that leads to “purposeful practice” has been democratized by the specialized social networks that now populate the Web. For example, rather than referencing a centrally controlled software engineering handbook, a software developer can pose a problem on an appropriate forum and obtain a crowd-sourced solution that draws from the experience of many other developers. The proposed solution if often critiqued in real time, with alternatives and adaptations offered as options.

但这并不是许多人所要求的纪律水平。正如 Shaw 所说:“软件工程师面临的问题越来越多地处于复杂的社会环境中,划定问题的边界也越来越困难”[Sha09]。因此,分离一门学科的科学基础仍然是一个挑战。在我们领域历史的这一点上,可以合理地说“到目前为止,新软件工程思想的发现自然是增量和进化的”[Erd10]。

But this is not the level of discipline that many demand. As Shaw states: “[P]roblems facing software engineers are increasingly situated in complex social contexts and delineating the problem’s boundaries is increasingly difficult” [Sha09]. As a consequence, isolating the scientific underpinnings of a discipline remains a challenge. At this point in the history of our field, it is reasonable to state that “the discovery of new software engineering ideas is, by now, naturally incremental and evolutionary” [Erd10].

29.3 观察软件工程趋势

29.3 Observing Software Engineering Trends

Barry Boehm [Boe08] 表示,“软件工程师将面临应对快速变化、不确定性和突发性、可靠性、多样性和相互依存性的巨大挑战,但他们也有机会做出重大贡献,为世界带来改变。更好的。” 但未来几年有哪些趋势可以帮助您应对这些挑战呢?

Barry Boehm [Boe08] suggests that “software engineers [will] face the formidable challenges of dealing with rapid change, uncertainty and emergence, dependability, diversity, and interdependence, but they also have opportunities to make significant contributions that will make a difference for the better.” But what are the trends that will enable you to face these challenges in the years ahead?

在本章的引言中,我们注意到“软趋势”对软件工程的整体方向具有重大影响。但其他(“更难”)研究和技术导向的趋势仍然很重要。研究趋势“由对现有技术和实践状况的普遍看法、研究人员对从业者需求的看法、围绕特定战略目标的国家资助计划以及纯粹的技术兴趣驱动”[Mil00b]。当研究趋势被推断以满足行业需求并由市场驱动的需求塑造时,技术趋势就会出现。

In the introduction to this chapter, we noted that “soft trends” have a significant impact on the overall direction of software engineering. But other (“harder”) research- and technology-oriented trends remain important. Research trends “are driven by general perceptions of the state of the art and the state of the practice, by researcher perceptions of practitioner needs, by national funding programs that rally around specific strategic goals, and by sheer technical interest” [Mil00b]. Technology trends occur when research trends are extrapolated to meet industry needs and are shaped by market-driven demand.

29.1节中,我们讨论了技术演化的S曲线模型。S曲线适合考虑核心技术发展的长期影响。但更温和、短期的创新、工具和方法又如何呢?Gartner Group [Gar08](一家研究多个行业技术趋势的咨询公司)开发了新兴技术的炒作周期,如图 29.2所示。“炒作周期”呈现了短期技术整合的现实观点。然而,长期趋势是指数级的。并非所有软件工程技术都能顺利通过炒作周期。在某些情况下,幻想破灭是有道理的,而这项技术则被归为默默无闻。第587页

In Section 29.1, we discussed the S-curve model for technology evolution. The S-curve is appropriate for considering the long-term effects of core technologies as they evolve. But what of more modest, short-term innovations, tools, and methods? The Gartner Group [Gar08]—a consultancy that studies technology trends across many industries—has developed a hype cycle for emerging technologies, represented in Figure 29.2. The “hype cycle” presents a realistic view of short-term technology integration. The long-term trend, however, is exponential. Not every software engineering technology makes it all the way through the hype cycle. In some cases, the disillusionment is justified, and the technology is relegated to obscurity.Page 587

29.2 Gartner Group 对新兴技术的炒作周期

Figure 29.2 The Gartner Group’s hype cycle for emerging technologies

资料来源:Linden、Alexander、Fenn、Jackie,“了解 Gartner 的炒作周期”,战略分析报告,Gartner, Inc.,2003 年 5 月 30 日,5。

Source: Linden, Alexander, Fenn, Jackie, “Understanding Gartner’s Hype Cycles,” Strategic Analysis Report, Gartner, Inc., May 30, 2003, 5.

29.4 识别“软趋势”

29.4 Identifying “Soft Trends”

每个拥有大量 IT 产业的国家都有一系列独特的特征,这些特征定义了业务开展的方式、公司内部出现的组织动态、适用于当地客户的独特营销问题以及支配所有人类的压倒性文化。相互作用。然而,这些领域中的一些趋势是普遍存在的,并且与社会学、人类学和群体心理学(通常称为“软科学”)的关系与学术或工业研究的关系一样多。

Each nation with a substantial IT industry has a set of unique characteristics that define the manner in which business is conducted, the organizational dynamics that arise within a company, the distinct marketing issues that apply to local customers, and the overriding culture that dictates all human interaction. However, some trends in each of these areas are universal and have as much to do with sociology, anthropology, and group psychology (often referred to as the “soft sciences”) as they do with academic or industrial research.

连接和协作(通过高带宽通信实现)已经导致软件团队不占据相同的物理空间(远程办公和本地环境下的兼职工作)。一个团队与不同时区、主要语言和文化的其他团队进行协作。软件工程必须为“分布式全球工程团队”提供一个总体流程模型,该模型足够敏捷,可以满足即时性需求,但又足够有纪律,可以协调不同的团队。

Connectivity and collaboration (enabled by high-bandwidth communication) has already led to software teams that do not occupy the same physical space (telecommuting and part-time employment in a local context). One team collaborates with other teams that are separated by time zones, primary language, and culture. Software engineering must respond with an overarching process model for “distributed global engineering teams” that is agile enough to meet the demands of immediacy but disciplined enough to coordinate disparate groups.

全球化导致劳动力多元化(在语言、文化、问题解决、管理理念、沟通优先级和人与人之间的互动方面)。这反过来又需要灵活的组织结构。不同的团队(位于不同的国家)必须以最适合其独特需求的方式应对工程问题,同时培养一定​​程度的一致性,使整个全球项目能够继续进行。这种类型的组织意味着管理级别较少,并且更加重视团队层面的决策。它可以带来更大的敏捷性,但前提是建立了沟通机制,以便每个团队都可以随时了解项目和技术状态(通过网络组件)。软件工程方法和工具可以帮助实现一定程度的一致性(团队使用通过特定方法和工具实现的相同“语言”)。软件过程可以为这些方法和工具的实例化提供框架。第588页

Globalization leads to a diverse workforce (in terms of language, culture, problem resolution, management philosophy, communication priorities, and person-to-person interaction). This, in turn, demands a flexible organizational structure. Different teams (in different countries) must respond to engineering problems in a way that best accommodates their unique needs, while at the same time fostering a level of uniformity that allows an overall global project to proceed. This type of organization suggests fewer levels of management and a greater emphasis on team-level decision making. It can lead to greater agility, but only if communication mechanisms have been established so that every team can understand project and technical status (via networked groupware) at any time. Software engineering methods and tools can help achieve some level of uniformity (teams speak the same “language” implemented through specific methods and tools). Software process can provide the framework for the instantiation of these methods and tools.Page 588

在世界一些地区(例如美国和欧洲),人口正在老龄化。这种不可否认的人口统计(和文化趋势)意味着许多经验丰富的软件工程师和管理人员将在未来几十年内离开该领域。软件工程社区必须以可行的机制来响应,以捕获这些老龄化管理人员和技术人员的知识[例如,模式的使用(第14章)是朝着正确方向迈出的一步],以便未来几代软件都可以使用它工人。在世界其他地区,从事软件行业的年轻人数量呈爆炸式增长。这提供了塑造软件工程文化的机会,而无需承受 50 年来“老派”偏见的负担。

In some world regions (the United States and Europe are examples), the population is aging. This undeniable demographic (and cultural trend) implies that many experienced software engineers and managers will be leaving the field over the coming decades. The software engineering community must respond with viable mechanisms that capture the knowledge of these aging managers and technologists [e.g., the use of patterns (Chapter 14) is a step in the right direction], so that it will be available to future generations of software workers. In other regions of the world, the number of young people available to the software industry is exploding. This provides an opportunity to mold a software engineering culture without the burden of 50 years of “old-school” prejudices.

据估计,未来十年将有超过 10 亿新消费者进入全球市场。到 2022 年,新兴经济体的消费者支出预计将增长至约 8 万亿美元 [Jai18]。该支出中受数字化影响的部分将超过 4 万亿美元。这意味着对新软件的需求不断增加。能否开发新的软件工程技术来满足这一全球需求?现代市场趋势往往是由供给侧驱动的。2在其他情况下,需求方的需求驱动着市场。无论哪种情况,创新和需求的循环都会以一种有时很难确定哪个先出现的方式进行!

It is estimated that over 1 billion new consumers will enter the worldwide marketplace over the next decade. Consumer spending in emerging economies is projected to grow to about $8 trillion by 2022 [Jai18]. The digitally influenced component of that spending will top $4 trillion. The implication—an increasing demand for new software. Can new software engineering technologies be developed to meet this worldwide demand? Modern market trends are often driven by the supply side.2 In other cases, demand-side requirements drive the market. In either case, a cycle of innovation and demand progresses in a way that sometimes makes it difficult to determine which came first!

最后,人类文化本身也会影响软件工程的方向。每一代人都会在当地文化中留下自己的印记,您的一代也不例外。Faith Popcorn [Pop08] 是一位专门研究文化趋势的著名顾问,他这样描述文化趋势:“我们的趋势不是时尚。我们的趋势经久不衰。我们的趋势不断发展。它们代表了潜在的力量、首要原因、人类的基本需求、态度和愿望。它们帮助我们探索世界,了解正在发生的事情和原因,并为即将发生的事情做好准备。” 关于现代文化趋势如何对软件工程产生影响的详细讨论最好留给那些专门研究“软科学”的人。

Finally, human culture itself will impact the direction of software engineering. Every generation establishes its own imprint on local culture, and yours will be no different. Faith Popcorn [Pop08], a well-known consultant who specializes in cultural trends, characterizes them in the following manner: “Our Trends are not fads. Our Trends endure. Our Trends evolve. They represent underlying forces, first causes, basic human needs, attitudes, aspirations. They help us navigate the world, understand what’s happening and why, and prepare for what is yet to come.” A detailed discussion of how modern cultural trends will have an impact on software engineering is best left to those who specialize in the “soft sciences.”

29.4.1 管理复杂性

29.4.1 Managing Complexity

当本书第一版撰写时(1982 年),我们现在所知道的数字消费产品还不存在,并且包含一百万行源代码(LOC)的基于大型机的系统被认为是相当大的。如今,小型数字设备通常包含 60,000 到 200,000 行定制软件,以及数百万个用于操作系统功能的 LOC。现代基于计算机的系统包含 10 到 5000 万行代码是很常见的。3在不久的将来,需要超过 10 亿 LOC 的系统4将开始出现。5第589页

When the first edition of this book was written (1982), digital consumer products as we now know them today didn’t exist, and mainframe-based systems containing a million lines of source code (LOC) were considered to be quite large. Today, small digital devices typically house between 60,000 to 200,000 lines of custom software, coupled with a few million LOC for operating system features. Modern computer-based systems containing 10 to 50 million lines of code are common.3 In the relatively near future, systems4 requiring over 1 billion LOC will begin to emerge.5Page 589

想一想!

Think about that for a moment!

考虑一下十亿个 LOC 系统的接口,包括与外部世界、其他可互操作系统、互联网(或其后继者)以及数百万个内部组件的接口,这些组件必须协同工作才能使这个计算怪物成功运行。是否有可靠的方法来确保所有这些连接都允许信息正常流动?

Consider the interfaces for a billion LOC system, both to the outside world, to other interoperable systems, to the Internet (or its successor), and to the millions of internal components that must all work together to make this computing monster operate successfully. Is there a reliable way to ensure that all these connections will allow information to flow properly?

考虑项目本身。我们如何管理工作流程并跟踪进度?传统方法会扩大几个数量级吗?

Consider the project itself. How do we manage the work flow and track progress? Will conventional approaches scale upward by orders of magnitude?

考虑将进行这项工作的人员数量(及其位置)、人员和技术的协调、持续不断的变更流、多平台、多操作系统环境的可能性。有没有办法管理和协调从事庞大项目的人员?

Consider the number of people (and their locations) who will be doing the work, the coordination of people and technology, the unrelenting flow of changes, the likelihood of a multiplatform, multioperating system environment. Is there a way to manage and coordinate people who are working on a monster project?

考虑工程挑战。我们如何分析数以万计的需求、约束和限制,确保发现并纠正不一致、模糊、遗漏和彻底的错误?我们如何创建一个足够强大的设计架构来处理这种规模的系统?软件工程师如何建立一个必须处理数十万个变更的变更管理系统?

Consider the engineering challenge. How can we analyze tens of thousands of requirements, constraints, and restrictions in a way that ensures that inconsistency and ambiguity, omissions, and outright errors are uncovered and corrected? How can we create a design architecture that is robust enough to handle a system of this size? How can software engineers establish a change management system that will have to handle hundreds of thousands of changes?

考虑质量保证的挑战。我们如何才能以有意义的方式进行验证和验证?如何测试 10 亿 LOC 系统?

Consider the challenge of quality assurance. How can we perform verification and validation in a meaningful way? How do you test a 1-billion-LOC system?

早期,软件工程师试图以一种只能被描述为临时方式来管理复杂性。今天,我们使用流程、方法和工具来控制复杂性。但明天呢?我们目前的方法能胜任这项任务吗?

In the early days, software engineers attempted to manage complexity in what can only be described as an ad-hoc fashion. Today, we use process, methods, and tools to keep complexity under control. But tomorrow? Is our current approach up to the task?

未来,我们可能会看到人工智能技术的更广泛应用来帮助软件工程师管理这些级别的复杂性 [Har12b]、[Xie18]。机器学习就是这样一种技术,可以帮助测试和错误修复[Mei18]。数据科学技术可用于帮助理解这些大型项目生成的大量软件工程数据 [Kim16b]。这些存储库的挖掘正在成为软件工程社区中公认的研究技术 [Dye15]。

In the future, we are likely to see wider use of artificial intelligence techniques to help software engineers manage these levels of complexity [Har12b], [Xie18]. Machine learning is one such technique that can help with testing and bug fixing [Mei18]. Data science techniques can be used to help make sense of the vast amount of software engineering data generated by these large projects [Kim16b]. Mining of these repositories is becoming an accepted research technique in the software engineering communities [Dye15].

29.4.2 开放世界软件

29.4.2 Open-World Software

环境智能、6 个上下文感知应用程序和普适计算等概念都致力于将基于软件的系统集成到比笔记本电脑、移动计算设备或任何其他数字设备更广泛的环境中。这些对计算近期未来的不同愿景共同提出了“开放世界软件”——旨在“通过自组织其结构和自适应其行为”来适应不断变化的环境的软件[Bar06b]。第590页

Concepts such as ambient intelligence,6 context-aware applications, and pervasive/ubiquitous computing all focus on integrating software-based systems into an environment far broader than a laptop, a mobile computing device, or any other digital device. These separate visions of the near-term future of computing collectively suggest “open-world software”—software that is designed to adapt to a continually changing environment “by self-organizing its structure and self-adapting its behavior” [Bar06b].Page 590

为了帮助说明软件工程师在不久的将来将面临的挑战,请考虑环境智能(amI)的概念。Ducatel [Duc01] 按以下方式定义 amI:“人们被嵌入各种对象中的智能、直观界面所包围。周围的智能环境能够以无缝、不引人注目的方式识别和响应不同个体的存在(在工作时)。”

To help illustrate the challenges that software engineers will face in the near future, consider the notion of ambient intelligence (amI). Ducatel [Duc01] defines amI in the following way: “People are surrounded by intelligent, intuitive interfaces that are embedded in all kinds of objects. The ambient intelligence environment is capable of recognizing and responding to the presence of different individuals [while working] in a seamless, unobtrusive way.”

随着低成本但功能日益强大的智能手机的广泛使用,我们正在迈向无处不在的人工智能系统。软件工程师面临的挑战是开发应用程序,为所有类型的产品提供不断增加的功能,即适应用户需求的功能,同时保护隐私和提供安全性。数字助理和智能聊天机器人的兴起预示着未来的应用类型。

With the widespread use of low-cost, yet increasingly powerful smartphones, we are well on our way to ubiquitous amI systems. The challenge for software engineers is to develop apps that provide ever-increasing functionality in products of all types—functionality that adapts to user needs while at the same time protecting privacy and providing security. The rise of digital assistants and intelligent chat bots are indicative of the types of applications ahead.

可变性密集型系统的工程重点关注需要适应不同使用和部署场景的软件,以及功能或质量属性(例如性能)的有意和无意的可变性。这包括应对上下文感知应用程序、自主代理和普适计算以及创建产品线软件带来的挑战。7这些系统在所有软件工程活动(例如,动态运行时条件、快速变化的需求、配置管理)中可能会发生很大的变化,我们需要提高对如何以经济有效的方式设计和管理它们的理解[ Gal17]。

The engineering of variability intensive systems focuses on software that needs to accommodate different usage and deployment scenarios, as well as intentional and unintentional variability in functionality or quality attributes (e.g., performance). This includes meeting the challenges posed by context-aware apps, autonomous agents, and pervasive computing as well as creating product-line software.7 These systems can be highly variable during all software engineering activities (e.g., dynamic run-time conditions, rapidly changing requirements, configuration management), and we need to improve our understanding of how to design and manage them in a cost-effective manner [Gal17].

29.4.3 紧急需求

29.4.3 Emergent Requirements

在软件项目开始时,有一条不言而喻的真理同样适用于所有参与的利益相关者:“你不知道自己不知道什么。” 这意味着客户很少定义“稳定”的需求。这也意味着软件工程师无法总是预见到歧义和不一致之处。需求发生变化——但这并不是什么新鲜事。

At the beginning of a software project, there’s a truism that applies equally to every stakeholder involved: “You don’t know what you don’t know.” That means that customers rarely define “stable” requirements. It also means that software engineers cannot always foresee where ambiguities and inconsistencies lie. Requirements change—but that’s nothing new.

随着系统变得越来越复杂,即使是陈述全面需求的基本尝试也注定会失败。总体目标的陈述也许是可能的,中期目标的描述是可以完成的,但稳定的要求——不是机会!当参与复杂系统的工程和构建的每个人都更多地了解它、它所处的环境以及将与之交互的用户时,需求就会出现。

As systems become more complex, it follows that even a rudimentary attempt to state comprehensive requirements is doomed to failure. A statement of overall goals may be possible, delineation of intermediate objectives can be accomplished, but stable requirements—not a chance! Requirements will emerge as everyone involved in the engineering and construction of a complex system learns more about it, the environment in which it is to reside, and the users who will interact with it.

这一现实意味着许多软件工程趋势。首先,流程模型的设计必须能够拥抱变化并采用敏捷哲学的基本原则(第 3 章)。接下来,必须明智地使用产生工程模型(例如,需求和设计模型)的方法,因为随着获得更多关于系统的知识,这些模型将反复变化。最后,支持流程和方法的工具必须使适应和改变变得容易。第591页

This reality implies a number of software engineering trends. First, process models must be designed to embrace change and adopt the basic tenets of the agile philosophy (Chapter 3). Next, methods that yield engineering models (e.g., requirements and design models) must be used judiciously because those models will change repeatedly as more knowledge about the system is acquired. Finally, tools that support both process and methods must make adaptation and change easy.Page 591

但紧急需求还有另一个方面。迄今为止开发的绝大多数软件都假设基于软件的系统与其外部环境之间的边界是稳定的。边界可能会发生变化,但会以受控的方式发生变化,从而允许软件作为常规软件维护周期的一部分进行调整。这种假设正在开始改变。可变性密集型系统的增长(第 29.4.2 节)要求软件“动态地适应变化并做出反应,即使它们是意料之外的”[Bar06b]。

But there is another aspect to emergent requirements. The vast majority of software developed to date assumes that the boundary between the software-based system and its external environment is stable. The boundary may change, but it will do so in a controlled manner, allowing the software to be adapted as part of a regular software maintenance cycle. This assumption is beginning to change. The growth of variability intensive systems (Section 29.4.2) demands that software “adapt and react to changes dynamically, even if they’re unanticipated” [Bar06b].

就其本质而言,紧急需求会导致变化。我们如何控制广泛使用的应用程序或系统在其生命周期内的演变,这对我们设计软件的方式有什么影响?

By their nature, emergent requirements lead to change. How do we control the evolution of a widely used application or system over its lifetime, and what effect does this have on the way we design software?

随着更改数量的增加,出现意外副作用的可能性也会增加。随着具有紧急需求的复杂系统成为常态,这应该引起人们的关注。软件工程社区必须开发方法来帮助软件团队预测整个系统的变化影响,从而减轻意外的副作用。今天,我们实现这一目标的能力受到严重限制。

As the number of changes grows, the likelihood of unintended side effects also grows. This should be a cause for concern as complex systems with emergent requirements become the norm. The software engineering community must develop methods that help software teams predict the impact of change across an entire system, thereby mitigating unintended side effects. Today, our ability to accomplish this is severely limited.

29.4.4 人才组合

29.4.4 The Talent Mix

随着基于软件的系统变得更加复杂,随着全球团队之间的沟通和协作变得司空见惯,随着紧急需求(以及由此产生的变更流)成为常态,软件工程团队的本质可能会发生变化。每个软件团队都必须将各种创造性人才和技术技能带到复杂系统的各个部分,并且整个流程必须允许这些人才孤岛的输出有效地融合。在软件工程的人性化方面使用数据挖掘进行知识发现可以帮助管理者在开始项目之前选择正确的开发团队[Gup15]。

As software-based systems become more complex, as communication and collaboration among global teams becomes commonplace, as emergent requirements (with the resultant flow of changes) become the norm, the very nature of a software engineering team may change. Each software team must bring a variety of creative talent and technical skills to its part of a complex system, and the overall process must allow the output of these islands of talent to merge effectively. Using data mining for knowledge discovery in the human aspects of software engineering may help managers select the right development team before beginning a project [Gup15].

Alexandra Weber-Morales [Mor05] 提出了“软件梦之队”的人才组合。大脑是一位首席架构师,能够引导利益相关者的需求并将其映射到可扩展和可实施的技术框架中Data Grrl是一位数据库和数据结构专家,他“对与关系模型相关的谓词逻辑和集合论有着深刻的理解,深入研究行和列”。阻止是技术领导者(经理),他允许团队在不受其他团队干扰的情况下工作,同时确保协作的发生。黑客是一位完美的程序员,熟悉模式和语言,并且能够有效地使用两者The Gatherer “巧妙地发现系统需求。。。人类学洞察力”并准确清晰地表达它们。

Alexandra Weber-Morales [Mor05] suggests the talent mix of a “software dream team.” The Brain is a chief architect who is able to navigate the demands of stakeholders and map them into a technology framework that is both extensible and implementable. The Data Grrl is a database and data structures guru who “blasts through rows and columns with profound understanding of predicate logic and set theory as it pertains to the relational model.” The Blocker is a technical leader (manager) who allows the team to work free of interference from other teams while at the same time ensuring that collaboration is occurring. The Hacker is a consummate programmer who is at home with patterns and languages and can use both effectively. The Gatherer “deftly discovers system requirements with . . . anthropological insight” and accurately expresses them with clarity.

29.4.5 软件构建块

29.4.5 Software Building Blocks

我们所有倡导软件工程哲学的人都强调重用源代码、面向对象的类、组件、模式和库的必要性。尽管软件工程社区在尝试捕获过去的知识并重用经过验证的解决方案方面取得了进展,但当今构建的软件中很大一部分仍然是“从头开始”构建的。造成这种情况的部分原因是(利益相关者和软件工程从业者)对“独特解决方案”的持续渴望。第592页

All of us who have fostered a software engineering philosophy have emphasized the need for reuse—of source code, object-oriented classes, components, patterns, and libraries. Although the software engineering community has made progress as it attempts to capture past knowledge and reuse proven solutions, a significant percentage of the software that is built today continues to be built “from scratch.” Part of the reason for this is a continuing desire (by stakeholders and software engineering practitioners) for “unique solutions.”Page 592

在硬件领域,数字设备的原始设备制造商 (OEM) 几乎完全使用芯片供应商生产的专用标准产品 (ASSP)。这种“商业硬件”提供了实现从智能手机到可穿戴计算设备等所有设备所需的构建模块。越来越多的 OEM 开始使用“商业软件”——专门为独特的应用领域(例如,互联网协议语音 (VoIP) 设备)设计的软件构建块。迈克尔·沃德 [War07] 评论:

In the hardware world, original equipment manufacturers (OEMs) of digital devices use application-specific standard products (ASSPs) produced by silicon vendors almost exclusively. This “merchant hardware” provides the building blocks necessary to implement everything from a smartphone to a wearable computing device. Increasingly, the same OEMs are using “merchant software”—software building blocks designed specifically for a unique application domain [e.g., Voice over Internet Protocol (VoIP) devices]. Michael Ward [War07] comments:

使用软件组件的优点之一是 OEM 可以利用软件提供的功能,而无需开发特定功能的内部专业知识或投入开发人员时间来实施和验证组件。其他优点包括仅获取和部署系统所需的特定功能集的能力,以及将这些组件集成到现有架构中的能力。

One advantage of the use of software components is that the OEM can leverage the functionality provided by the software without having to develop in-house expertise in the specific functions or invest developer time on the effort to implement and validate the components. Other advantages include the ability to acquire and deploy only the specific set of functionalities that are needed for the system, as well as the ability to integrate these components into an already-existing architecture.

除了打包为商业软件的组件之外,越来越多的趋势是采用“包含相关功能集合的软件平台解决方案,通常在集成软件框架内提供”[War07]。软件平台将 OEM 从与开发基本功能相关的工作中解放出来,并允许 OEM 将软件精力投入到那些使其产品与众不同的功能上。

In addition to components packaged as merchant software, there is an increasing tendency to adopt software platform solutions that “incorporate collections of related functionalities, typically provided within an integrated software framework” [War07]. A software platform frees an OEM from the work associated with developing base functionality and instead allows the OEM to dedicate software effort on those features that differentiate its product.

29.4.6 改变对“价值”的看法

29.4.6 Changing Perceptions of “Value”

在二十世纪最后二十五年,商人在讨论软件时提出的一个重要问题是:为什么它的成本如此之高?如今这个问题很少被问到,取而代之的是:为什么我们不能更快地获得它(软件和/或基于软件的产品)?

During the last quarter of the twentieth century, the operative question that businesspeople asked when discussing software was: Why does it cost so much? That question is rarely asked today and has been replaced by: Why can’t we get it (software and/or the software-based product) sooner?

当考虑计算机软件时,现代的价值观念正在从商业价值(成本和盈利能力)转变为客户价值,包括:交付速度、功能丰富性和整体产品质量。

When computer software is considered, the modern perception of value is changing from business value (cost and profitability) to customer values that include: speed of delivery, richness of functionality, and overall product quality.

29.4.7 开源

29.4.7 Open Source

谁拥有您或您的组织使用的软件?越来越多的答案是“每个人”。“开源”运动是这样描述的 [OSO12]:“开源是一种软件开发方法,它利用分布式同行评审和流程透明度的力量。开源的承诺是更好的质量、更高的可靠性、更大的灵活性、更低的成本,并结束掠夺性的供应商锁定。” 当术语“开源”应用于计算机软件时,意味着软件工程工作产品(模型、源代码、测试套件)向公众开放,任何有兴趣并获得许可的人都可以对其进行审查和扩展(通过控制)。

Who owns the software you or your organization uses? Increasingly, the answer is “everyone.” The “open source” movement has been described in the following manner [OSO12]: “Open source is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.” The term open source, when applied to computer software, implies that software engineering work products (models, source code, test suites) are open to the public and can be reviewed and extended (with controls) by anyone with interest and permission.

如果您有进一步的兴趣,Weber [Web05] 提供了有价值的介绍,Feller 和他的同事 [Fel07] 编辑了一本全面而客观的选集,考虑了与开源相关的好处和问题,Brown [Bro12] 提供了更多技术讨论。

If you have further interest, Weber [Web05] provides a worthwhile introduction, Feller and his colleagues [Fel07] have edited a comprehensive and objective anthology that considers the benefits and problems associated with open source, and Brown [Bro12] provides a more technical discussion.

第593页

Page 593

29.5 技术方向

29.5 Technology Directions

我们似乎总是认为软件工程的变化速度会比实际情况更快。一种新的“炒作”技术(它可能是一种新工艺、一种独特的方法或一种令人兴奋的工具)被引入,专家认为“一切”都会改变。但软件工程不仅仅关乎技术,它还关乎人们以及他们沟通需求和创新以使这些需求成为现实的能力。只要有人参与,变化就会断断续续地缓慢发生。只有当达到“临界点”[Gla02] 时,技术才会在软件工程社区中级联,并且真正发生广泛的变革。

We always seem to think that software engineering will change more rapidly than it does. A new “hyped” technology (it could be a new process, a unique method, or an exciting tool) is introduced, and pundits suggest that “everything” will change. But software engineering is about far more than technology—it’s about people and their ability to communicate their needs and innovate to make those needs a reality. Whenever people are involved, change occurs slowly in fits and starts. It’s only when a “tipping point” [Gla02] is reached that a technology cascades across the software engineering community and broad-based change truly does occur.

在本节中,我们将研究流程、方法和工具方面的一些趋势,这些趋势可能会对未来十年的软件工程产生一些影响。它们会导致一个转折点吗?我们只能拭目以待。

In this section we’ll examine a few trends in process, methods, and tools that are likely to have some influence on software engineering over the next decade. Will they lead to a tipping point? We’ll just have to wait and see.

29.5.1 过程趋势

29.5.1 Process Trends

可以说,第 28 章中讨论的所有商业、组织和文化趋势都提供了未来的路线图?流程框架是否会不断发展以在纪律和创造力之间找到更好的平衡?软件流程是否能够适应采购软件、构建软件和使用软件的利益相关者的不同需求?它能否提供一种同时降低所有三个选区风险的方法?

It can be argued that all the business, organizational, and cultural trends discussed in Chapter 28 provide a road map into the future? Will process frameworks evolve to find a better balance between discipline and creativity? Will the software process adapt to the differing needs of stakeholders who procure software, those who build it, and those who use it? Can it provide a means for reducing risk for all three constituencies at the same time?

这些问题和许多其他问题仍然悬而未决。在接下来的段落中,我们采用了 Conradi 和 Fuggetta [Con02] 提出的六个想法来建议可能的过程趋势。

These and many other questions remain open. In the paragraphs that follow, we have adapted six ideas proposed by Conradi and Fuggetta [Con02] to suggest possible process trends.

  1. 随着 SPI 框架的发展,它们将强调“专注于目标导向和产品创新的策略” [Con02]。在快节奏的软件开发领域,长期的 SPI 策略很少能在动态的商业环境中生存。变化太多太快。这意味着 SPI 的稳定、分步路线图可能必须被强调以产品为导向的短期目标的框架所取代。

  2. As SPI frameworks evolve, they will emphasize “strategies that focus on goal orientation and product innovation” [Con02]. In the fast-paced world of software development, long-term SPI strategies rarely survive in a dynamic business environment. Too much changes too quickly. This means that a stable, step-by-step road map for SPI may have to be replaced with a framework that emphasizes short-term goals that have a product orientation.

  3. 因为软件工程师对流程的薄弱环节有很好的认识,所以流程变更通常应该由他们的需求驱动,并且应该从下到上开始。Conradi 和 Fuggetta [Con02] 建议未来的 SPI 活动应该“使用简单且有针对性的记分卡来开始,而不是进行大型评估。” 通过集中 SPI 工作并自下而上地工作,从业者将开始尽早看到实质性的变化,这些变化对软件工程工作的进行方式产生了真正的影响。

  4. Because software engineers have a good sense of where the process is weak, process changes should generally be driven by their needs and should start from the bottom up. Conradi and Fuggetta [Con02] suggest that future SPI activities should “use a simple and focused scorecard to start with, not a large assessment.” By focusing SPI efforts narrowly and working from the bottom up, practitioners will begin to see substantive changes early—changes that make a real difference in the way that software engineering work is conducted.

  5. 自动化软件流程技术(SPT)将从全局流程管理(对整个软件流程的广泛支持)转向专注于软件流程中最能从自动化中受益的方面。没有人反对工具和自动化,但在许多情况下,SPI 并未兑现其承诺(请参阅第 1 章)——软件过程中最稳定的元素。

  6. Automated software process technology (SPT) will move away from global process management (broad-based support of the entire software process) to focus on those aspects of the software process that can best benefit from automation. No one is against tools and automation, but in many instances, SPI has not met its promise (see Chapter 1)—the most stable elements of the software process.

  7. 第594页将更加重视 SPI 活动的投资回报。第 28 章中,您了解到投资回报率 (ROI) 可以定义为:

    迄今为止,软件组织一直在努力以定量的方式清楚地描述“好处”。[Con02] 可以说“因此我们需要一个标准化的市场价值模型……”。。。考虑到软件改进举措。”

  8. Page 594Greater emphasis will be placed on the return on investment of SPI activities. In Chapter 28 you learned that return on investment (ROI) can be defined as:

    To date, software organizations have struggled to clearly delineate “benefits” in a quantitative manner. It can be argued [Con02] that “we therefore need a standardized market-value model . . . to account for software improvement initiatives.”

  9. 随着时间的推移,软件社区可能会逐渐认识到,社会学和人类学方面的专业知识可能与其他技术性更强的学科一样,与成功的 SPI 有着同等甚至更多的关系。最重要的是,SPI 改变了组织文化,而文化变革涉及个人和群体。Conradi 和 Fuggetta [Con02] 正确地指出“软件开发人员是知识工作者。他们往往会对高层关于如何开展工作或改变流程的指示作出消极反应。” 通过研究群体社会学可以学到很多东西,以更好地理解引入变革的有效方法。

  10. As time passes, the software community may come to understand that expertise in sociology and anthropology may have as much or more to do with successful SPI as other, more technical disciplines. More than anything else SPI changes organizational culture, and cultural change involves individuals and groups of people. Conradi and Fuggetta [Con02] correctly note that “software developers are knowledge workers. They tend to respond negatively to top-level dictates on how to do work or change processes.” Much can be learned by examining the sociology of groups to better understand effective ways to introduce change.

  11. 新的学习模式可能会促进向更有效的软件流程的过渡。在这种情况下,“学习”意味着从成功和错误中学习。收集度量标准(第 23 章)的软件组织可以让自己了解流程的元素如何影响最终产品的质量。

  12. New modes of learning may facilitate the transition to a more effective software process. In this context, “learning” implies learning from successes and mistakes. A software organization that collects metrics (Chapter 23) allows itself to understand how elements of a process affect the quality of the end product.

29.5.2 大挑战

29.5.2 The Grand Challenge

有一个不可否认的趋势——随着时间的推移,基于软件的系统无疑会变得更大、更复杂。正是这些大型、复杂系统的工程,无论交付平台或应用领域如何,都给软件工程师带来了“巨大的挑战”[Bro06]。Manfred Broy [Bro06] 建议软件工程师可以通过创建新的方法来理解系统模型并将这些模型用作构建高质量下一代软件的基础,从而应对“复杂软件系统开发的艰巨挑战”。目前正在研究的可变性密集型系统技术(持续交付、自适应软件、基于价值的软件工程、内容感知计算)可能会使所有类型的软件产品的开发人员受益[Gal17]。

There is one trend that is undeniable—software-based systems will undoubtedly become bigger and more complex as time passes. It is the engineering of these large, complex systems, regardless of delivery platform or application domain, that poses the “grand challenge” [Bro06] for software engineers. Manfred Broy [Bro06] suggests that software engineers can meet “the daunting challenge of complex software systems development” by creating new approaches to understanding system models and using those models as a basis for the construction of high-quality next-generation software. Techniques currently being studied for variability intensive systems (continuous delivery, self-adaptive software, value-based software engineering, content aware computing) may benefit the developers of all types of software products [Gal17].

随着软件工程社区开发新的模型驱动方法(本节稍后简要讨论)来表示系统需求和设计,必须解决以下特征 [Bro06]:

As the software engineering community develops new model-driven approaches (discussed briefly later in this section) to the representation of system requirements and design, the following characteristics [Bro06] must be addressed:

  • 多功能性。随着数字设备的发展,它们已经开始提供丰富的有时不相关的功能。移动电话曾经被认为是一种简单的通信设备,现已成为一种功能强大的袖珍电脑,可以执行多种功能,这些功能可以说比打电话更重要。正如 Broy [Bro06] 指出的那样,“工程师必须描述交付功能的详细上下文,最重要的是,必须识别系统不同功能之间潜在有害的交互。”第595页

  • Multifunctionality. As digital devices evolve, they have begun to deliver a rich set of sometimes unrelated functions. The mobile phone, once considered a straightforward communication device, has become a powerful pocket computer that performs a wide spectrum of functions that are arguably more important than making a phone call. As Broy [Bro06] notes, “[E]ngineers must describe the detailed context in which the functions will be delivered and, most important, must identify the potentially harmful interactions between the system’s different features.”Page 595

  • 反应性和及时性。数字设备越来越多地与现实世界交互,并且必须及时对外部刺激做出反应。它们必须与广泛的传感器连接,并且必须在适合手头任务的时间内做出响应。必须开发新方法,以(1)帮助软件工程师预测各种反应性功能的时序,以及(2)以一种减少机器依赖且更便携的方式实现这些功能。

  • Reactivity and timeliness. Digital devices increasingly interact with the real world and must react to external stimuli in a timely manner. They must interface with a broad array of sensors and must respond in a period that is appropriate to the task at hand. New methods must be developed that (1) help software engineers predict the timing of various reactive features and (2) implement those features in a way that makes the feature less machine dependent and more portable.

  • 用户交互的新模式。软件的开放世界趋势意味着必须建模和实施新的交互模式。无论这些新方法使用多点触控界面、语音识别还是直接思维界面,新一代数字设备软件都必须适应它们。

  • New modes of user interaction. Open-world trends for software mean that new modes of interaction must be modeled and implemented. Whether these new approaches use multitouch interfaces, voice recognition, or direct mind interfaces, new generations of software for digital devices must accommodate them.

  • 复杂的架构。豪华汽车拥有 2,000 多种功能,这些功能由驻留在复杂硬件架构中的软件控制,其中包括多个处理器、复杂的总线结构、执行器、传感器、日益复杂的人机界面以及许多安全组件。更复杂的系统(例如自动驾驶汽车)即将出现,这给软件设计人员带来了巨大的挑战。

  • Complex architectures. A luxury automobile has over 2,000 functions controlled by software residing within a complex hardware architecture that includes multiple processors, a sophisticated bus structure, actuators, sensors, an increasingly sophisticated human interface, and many safety-rated components. Even more complex systems (e.g., autonomous vehicles) are on the immediate horizon, presenting significant challenges for software designers.

  • 异构、分布式系统。任何现代嵌入式系统的实时组件都可以通过内部总线、无线网络或互联网(或全部三者)进行连接。

  • Heterogeneous, distributed systems. The real-time components of any modern embedded system can be connected via an internal bus, a wireless network, or across the Internet (or all three).

  • 批判性。软件已成为几乎所有业务关键型系统和大多数安全关键型系统中的关键组件。然而,软件工程社区才刚刚开始应用最基本的软件安全原则。

  • Criticality. Software has become the pivotal component in virtually all business-critical systems and in most safety-critical systems. Yet, the software engineering community has only begun to apply even the most basic principles of software safety.

  • 维护可变性。数字设备中软件的使用寿命很少超过 3 到 5 年,但飞机中复杂的航空电子系统的使用寿命至少为 20 年。汽车软件介于两者之间。这应该对设计产生影响吗?

  • Maintenance variability. The life of software within a digital device rarely lasts beyond 3 to 5 years, but the complex avionics systems within an aircraft has a useful life of at least 20 years. Automobile software falls somewhere in between. Should this have an impact on design?

Broy [Bro06] 认为,只有软件工程社区开发出更有效的分布式和协作式软件工程理念、更好的需求工程方法、更稳健的模型驱动开发方法以及更好的软件工具,才能管理这些和其他软件特性。 。在接下来的部分中,我们将简要探讨每个领域。

Broy [Bro06] argues that these and other software characteristics can be managed only if the software engineering community develops a more effective distributed and collaborative software engineering philosophy, better requirements engineering approaches, a more robust approach to model-driven development, and better software tools. In the sections that follow, we’ll explore each of these areas briefly.

29.5.3 协同开发

29.5.3 Collaborative Development

这似乎太明显了,无法说明,但无论如何我们都会这样做:软件工程是一种信息技术。从任何软件项目开始,每个利益相关者都必须共享信息——关于基本业务目标和目的、关于特定系统需求、关于架构设计问题、关于要构建的软件的几乎每个方面。协作涉及及时传播信息以及有效的沟通和决策过程。

It seems too obvious to state, but we’ll do so anyway: Software engineering is an information technology. From the onset of any software project, every stakeholder must share information—about basic business goals and objectives, about specific system requirements, about architectural design issues, about almost every aspect of the software to be built. Collaboration involves the timely dissemination of information and an effective process for communication and decision making.

如今,软件工程师跨越时区和国际边界进行协作。他们每个人都必须共享信息。对于开源项目也是如此,其中成百上千的软件开发人员致力于构建开源应用程序。众包已被建议作为增强自动化测试工具生成的覆盖率测试用例的一种手段[Mao17]。如此大型的测试社区的协调将具有挑战性。必须传播信息,以便能够进行开放式合作。第596页

Today, software engineers collaborate across time zones and international boundaries. Every one of them must share information. The same holds for open-source projects in which hundreds or thousands of software developers work to build an open-source app. Crowd sourcing has been suggested as a means of enhancing coverage test cases generated by automated testing tools [Mao17]. Coordination of such large testing communities will be challenging. Information must be disseminated so that open collaboration can occur.Page 596

29.5.4 需求工程

29.5.4 Requirements Engineering

第 7 章和第 8章介绍了基本的需求工程操作——启发、阐述、协商、规范和验证。这些动作的成功或失败对整个软件工程过程的成功或失败有非常大的影响。然而,需求工程 (RE) 被比作“尝试在果冻周围放置软管夹”[Gon04]。正如我们在本书的许多地方所指出的,软件需求有不断变化的趋势,并且随着开放世界系统的出现,紧急需求(以及近乎持续的变化)可能会成为常态。

Basic requirements engineering actions—elicitation, elaboration, negotiation, specification, and validation—were presented in Chapters 7 and 8. The success or failure of these actions has a very strong influence on the success or failure of the entire software engineering process. And yet, requirements engineering (RE) has been compared to “trying to put a hose clamp around jello” [Gon04]. As we’ve noted in many places throughout this book, software requirements have a tendency to keep changing, and with the advent of open-world systems, emergent requirements (and near-continuous change) may become the norm.

如今,大多数“非正式”需求工程方法都是从创建用户场景(例如,用例)开始的。更正式的方法创建一个或多个需求模型并将其用作设计的基础。形式化方法使软件工程师能够使用可验证的数学符号来表示需求。当需求稳定时,所有这些都可以很好地工作,但不能轻易解决动态或紧急需求的问题。

Today, most “informal” requirements engineering approaches begin with the creation of user scenarios (e.g., use cases). More formal approaches create one or more requirements models and use these as a basis for design. Formal methods enable a software engineer to represent requirements using a verifiable mathematical notation. All can work reasonably well when requirements are stable, but do not readily solve the problem of dynamic or emergent requirements.

有许多不同的需求工程研究方向,包括从翻译的文本描述到更结构化的表示(例如分析类)的自然语言处理、更多地依赖数据库来构建和理解软件需求、使用 RE 模式来描述典型问题和进行需求工程任务时的解决方案,以及面向目标的需求工程。然而,在行业层面,可再生能源行动仍然相对非正式,而且令人惊讶地基本。为了改进定义需求的方式,软件工程社区可能会在进行 RE 时实施三个不同的子流程 [Gli07]:(1)改进知识获取和知识共享,以便更全面地理解应用程序领域约束和涉众需求, (2) 在定义需求时更加强调迭代,(3) 更有效的沟通和协调工具,使所有利益相关者能够有效协作。

There are a number of distinct requirements engineering research directions including natural language processing from translated textual descriptions into more structured representations (e.g., analysis classes), greater reliance on databases for structuring and understanding software requirements, the use of RE patterns to describe typical problems and solutions when requirements engineering tasks are conducted, and goal-oriented requirements engineering. However, at the industry level, RE actions remain relatively informal and surprisingly basic. To improve the manner in which requirements are defined, the software engineering community will likely implement three distinct subprocesses as RE is conducted [Gli07]: (1) improved knowledge acquisition and knowledge sharing that allows more complete understanding of application domain constraints and stakeholder needs, (2) greater emphasis on iteration as requirements are defined, and (3) more effective communication and coordination tools that enable all stakeholders to collaborate effectively.

上一段提到的 RE 子流程只有正确集成到不断发展的软件工程方法中才会成功。随着基于模式的问题解决和基于组件的解决方案开始主导许多应用领域,RE 必须满足对敏捷性(快速增量交付)的需求以及由此产生的固有的紧急需求。静态“软件规范”的概念开始消失,取而代之的是“价值驱动的需求”[Som05],这些需求是利益相关者对早期软件增量中提供的特性和功能做出反应而衍生的。

The RE subprocesses noted in the preceding paragraph will only succeed if they are properly integrated into an evolving approach to software engineering. As pattern-based problem solving and component-based solutions begin to dominate many application domains, RE must accommodate the desire for agility (rapid incremental delivery) and the inherent emergent requirements that result. The notion of a static “software specification” is beginning to disappear, to be replaced by “value-driven requirements” [Som05] derived as stakeholders respond to features and functions delivered in early software increments.

29.5.5 模型驱动的软件开发

29.5.5 Model-Driven Software Development

第597页软件工程师几乎在软件工程过程的每个步骤中都在努力解决抽象问题。当设计开始时,架构和组件级抽象被表示和评估。然后必须将它们转换为编程语言表示,将设计(相对较高的抽象级别)转换为具有特定计算环境(较低的抽象级别)的可操作系统。模型驱动的软件开发8将特定于领域的建模语言与转换引擎和生成器结合起来,以促进高层抽象表示,然后将其转换为较低层 [Sch06]。模型驱动方法解决了所有软件开发人员面临的持续挑战——如何以比代码更高的抽象级别表示软件。

Page 597Software engineers grapple with abstraction at virtually every step in the software engineering process. As design commences, architectural and component-level abstractions are represented and assessed. They must then be translated into a programming language representation that transforms the design (a relatively high level of abstraction) into an operable system with a specific computing environment (a low level of abstraction). Model-driven software development8 couples domain-specific modeling languages with transformation engines and generators in a way that facilitates the representation of abstraction at high levels and then transforms it into lower levels [Sch06]. Model-driven approaches address a continuing challenge for all software developers—how to represent software at a higher level of abstraction than code.

领域特定建模语言(DSML)表示“特定应用程序域内的应用程序结构、行为和需求”,并用元模型进行描述,元模型“定义域中概念之间的关系,并精确指定与这些域相关的关键语义和约束”概念”[Sch06]。DSML 与通用建模语言(例如 UML(附录 1))之间的主要区别在于,DSML 针对应用程序域中固有的设计概念进行了调整,因此可以以有效的方式表示设计元素之间的关系和约束。

Domain-specific modeling languages (DSMLs) represent “application structure, behavior and requirements within particular application domains” and are described with meta-models that “define the relationships among concepts in the domain and precisely specify the key semantics and constraints associated with these domain concepts” [Sch06]. The key difference between a DSML and a general-purpose modeling language such as UML (Appendix 1) is that the DSML is tuned to design concepts inherent in the application domain and can therefore represent relationships and constraints among design elements in an efficient manner.

29.5.6 基于搜索的软件工程

29.5.6 Search-Based Software Engineering

软件工程中的许多活动都可以表述为优化问题。基于搜索的软件工程(SBSE) 将遗传算法9等元启发式搜索技术应用于软件工程问题。Lionel Briand [Bri09] 认为,进化和其他搜索技术比模型驱动技术更容易扩展到工业规模的问题,并且两者之间存在协同的机会。基于搜索的软件工程的设计前提是,检查候选解决方案是否解决问题通常比从头开始构建解决方案更容易[Kul13]。

Many activities in software engineering can be stated as optimization problems. Search-based software engineering (SBSE) applies metaheuristic search techniques such as genetic algorithms9 to software engineering problems. Lionel Briand [Bri09] believes that evolutionary and other search techniques are more easily scaled to industrial-size problems than model-driven techniques and that there are opportunities for synergy between the two. Search-based software engineering was devised on the premise that it is often easier to check that a candidate solution solves a problem than it is to construct a solution from scratch [Kul13].

基于搜索的软件工程技术可以作为遗传改进的基础,通过将新的功能和非功能特性嫁接到现有的软件产品线中来开发软件产品[Har14]。软件的遗传改进已经导致现有软件产品的性能显着提高(例如,执行时间、能源使用和内存消耗)[Pet18]。成功的软件产品不断发展;然而,如果管理不当,演化可能会削弱软件质量,并且可能需要重构才能保持可行性。

Search-based software engineering techniques can be used as the basis for genetic improvement to grow software products by grafting on new functional and nonfunctional features to existing software product line [Har14]. Genetic improvement of software has already resulted in dramatic performance improvements (e.g., execution time, energy usage, and memory consumption) in existing software products [Pet18]. Successful software products evolve continually; however, evolution, if not properly managed, may weaken the software quality and may need to be refactored to remain viable.

基于搜索的软件工程技术已用于生成和修复重构建议序列。手动创建重构建议非常耗时。使用动态、交互式方法生成重构建议可以提高软件质量,同时最大限度地减少与原始设计的偏差 [Ali18]。基于搜索的软件工程技术已用于设计测试用例,以评估开发人员在崩溃后对软件的修复[Als18]。这些技术可能会导致软件系统能够自我修复。第598页

Search-based software engineering techniques have been used to generate and repair sequences of refactoring recommendations. It is time consuming to create refactoring recommendations manually. Using a dynamic, interactive approach to generate refactoring recommendations can improve software quality while minimizing deviations from the original design [Ali18]. Search-based software engineering techniques have been used to design test cases to evaluate developer fixes to the software following crashes [Als18]. It is possible that these techniques may lead to software systems capable of repairing themselves.Page 598

29.5.7 测试驱动开发

29.5.7 Test-Driven Development

需求驱动设计,设计为施工奠定基础。这个简单的软件工程现实运行得相当好,并且对于创建软件架构来说是必不可少的。然而,当考虑组件级设计和构造时,细微的改变可以带来显着的好处。

Requirements drive design, and design establishes a foundation for construction. This simple software engineering reality works reasonably well and is essential as a software architecture is created. However, a subtle change can provide significant benefit when component-level design and construction are considered.

测试驱动开发(TDD)中软件组件的需求作为创建一系列测试用例的基础,这些测试用例测试接口并尝试查找组件提供的数据结构和功能中的错误。TDD 并不是真正的新技术,而是一种强调在创建源代码之前设计测试用例的趋势。10

In test-driven development (TDD), requirements for a software component serve as the basis for the creation of a series of test cases that exercise the interface and attempt to find errors in the data structures and functionality delivered by the component. TDD is not really a new technology but rather a trend that emphasizes the design of test cases before the creation of source code.10

TDD 流程遵循图 29.3所示的简单流程。在创建第一小段代码之前,软件工程师会创建一个测试来测试代码(尝试使代码失败)。然后编写代码以满足测试。如果通过,则会为要开发的下一段代码创建一个新测试。该过程一直持续到组件完全编码并且所有测试执行都没有错误为止。但是,如果任何测试成功发现错误,则会重构(更正)现有代码,并再次执行到该点创建的所有测试。此迭代流程一直持续到没有剩余测试可供创建,这意味着该组件满足为其定义的所有要求。

The TDD process follows the simple procedural flow illustrated in Figure 29.3. Before the first small segment of code is created, a software engineer creates a test to exercise the code (to try to make the code fail). The code is then written to satisfy the test. If it passes, a new test is created for the next segment of code to be developed. The process continues until the component is fully coded and all tests execute without error. However, if any test succeeds in finding an error, the existing code is refactored (corrected) and all tests created to that point are executed again. This iterative flow continues until there are no tests left to be created, implying that the component meets all requirements defined for it.

图29.3测试 驱动开发流程

Figure 29.3 Test-driven development process flow

第599页在 TDD 期间,代码以非常小的增量开发(一次一个子功能),并且在存在测试来执行代码之前不会编写任何代码。您应该注意,每次迭代都会产生一个或多个新测试,这些测试将添加到随每次更改一起运行的回归测试套件中。这样做是为了确保新代码不会产生导致旧代码错误的副作用。如果您对 TDD 有进一步的兴趣,请参阅 [Bec04b]、[Ste10] 或 [Whi12]。

Page 599During TDD, code is developed in very small increments (one subfunction at a time), and no code is written until a test exists to exercise it. You should note that each iteration results in one or more new tests that are added to a regression test suite that is run with every change. This is done to ensure that the new code has not generated side effects that cause errors in the older code. If you have further interest in TDD, see [Bec04b], [Ste10], or [Whi12].

29.6 工具相关趋势

29.6 Tools-Related Trends

每年都会推出数百种工业级软件工程工具。大多数是由工具供应商提供的,他们声称他们的工具将改进项目管理,或需求分析,或设计建模,或代码生成,或测试,或变更管理,或所讨论的许多软件工程活动、操作和任务中的任何一个贯穿本书。其他工具已作为开源产品开发。大多数开源工具都专注于“编程”活动,特别强调构建活动(特别是代码生成)。还有其他工具是从大学和政府实验室的研究工作中发展出来的。尽管它们在非常有限的应用中具有吸引力,但大多数还没有为广泛的行业应用做好准备。

Hundreds of industry-grade software engineering tools are introduced each year. The majority are provided by tools vendors who claim that their tool will improve project management, or requirements analysis, or design modeling, or code generation, or testing, or change management, or any of the many software engineering activities, actions, and tasks discussed throughout this book. Other tools have been developed as open-source offerings. The majority of open-source tools focus on “programming” activities with a specific emphasis on the construction activity (particularly code generation). Still other tools grow out of research efforts at universities and government labs. Although they have appeal in very limited applications, the majority are not ready for broad industry application.

在行业层面,最全面的工具包形成了软件工程环境(SEE) 11,它围绕中央数据库(存储库)集成了一系列单独的工具。当作为一个整体考虑时,SEE 集成了整个软件流程中的信息,并有助于许多大型、复杂的基于软件的系统所需的协作。但是当前的环境不容易扩展(很难集成不属于软件包一部分的 COTS 工具)并且往往是通用的(即,它们不是特定于应用程序域的)。新技术解决方案(例如模型驱动软件开发)的引入与支持新技术的可行 SEE 的可用性之间也存在很大的时间滞后。

At the industry level, the most comprehensive tools packages form software engineering environments (SEEs)11 that integrate a collection of individual tools around a central database (repository). When considered as a whole, a SEE integrates information across the software process and assists in the collaboration that is required for many large, complex software-based systems. But current environments are not easily extensible (it’s difficult to integrate a COTS tool that is not part of the package) and tend to be general purpose (i.e., they are not application domain specific). There is also a substantial time lag between the introduction of new technology solutions (e.g., model-driven software development) and the availability of viable SEEs that support the new technology.

过去,软件工具遵循两条不同的路径——一条以人为本的路径,响应第 29.4 节中讨论的一些“软趋势” ,一条以技术为中心的路径,在新技术(第 25.5 节)被引入和使用时解决它们。通过了。展望未来,软件工程师开始构建专注于人类与技术交互的工具。机器生成的解决方案并不总是适用于所有问题。仍然需要人类来决定是否接受机器推荐。

In the past, software tools followed two distinct paths—a human-focused path that responds to some of the “soft trends” discussed in Section 29.4, and a technology-centered path that addresses new technologies (Section 25.5) as they are introduced and adopted. Moving forward, software engineers are beginning to build tools that focus on the interaction of humans and technology. Machine-generated solutions do not always apply to every problem. Humans are still needed to make the decision to accept a machine recommendation or not.

第 29.4 节中讨论的软趋势——需要管理复杂性、适应紧急需求、建立拥抱变化的流程模型、协调全球团队与不断变化的人才组合等等——表明了一个新时代,在这个新时代中,支持利益相关者协作的工具将成为与工具对技术的支持一样重要。

The soft trends discussed in Section 29.4—the need to manage complexity, accommodate emergent requirements, establish process models that embrace change, coordinate global teams with a changing talent mix, among others—suggest a new era in which tools support for stakeholder collaboration will become as important as tools support for technology.

当利益相关者作为一个团队工作时,软件工程的敏捷性(第 3 章)就可以实现。因此,即使软件是本地开发的,协作 SEE 的趋势也会带来好处。但是,补充系统和组件以实现更好协作的技术工具又如何呢?第 600 页

Agility in software engineering (Chapter 3) is achieved when stakeholders work as a team. Therefore, the trend toward collaborative SEEs will provide benefits even when software is developed locally. But what of the technology tools that complement the system and components that empower better collaboration?Page 600

技术工具的主要趋势之一是创建支持模型驱动开发(第 29.5.5 节)并强调架构驱动设计的工具集。Oren Novotny [Nov04] 建议模型而不是源代码成为软件工程的中心焦点:

One of the dominant trends in technology tools is the creation of a tool set that supports model-driven development (Section 29.5.5) with an emphasis on architecture-driven design. Oren Novotny [Nov04] suggests that the model rather than the source code becomes the central software engineering focus:

独立于平台的模型是在 UML 中创建的,然后经过各种级别的转换,最终成为特定平台的源代码。那么,模型(而不是文件)应该成为新的输出单位,这是有道理的。模型在不同的抽象级别上有许多不同的视图。在最高级别,可以在分析中指定与平台无关的组件;在最低级别,有一个特定于平台的实现,可简化为代码中的一组类。

Platform independent models are created in UML and then undergo various levels of transformation to eventually wind up as source code for a specific platform. It makes sense then, that the model, not the file, should become the new unit of output. A model has many different views at different levels of abstraction. At the highest level, platform independent components can be specified in analysis; at the lowest level there is a platform specific implementation that reduces to a set of classes in code.

Novotny 认为,新一代工具将与存储库结合使用,在所有必要的抽象级别上创建模型,建立各种模型之间的关系,将一个抽象级别的模型转换为另一个抽象级别(例如,将设计模型转换为源代码),管理变更和版本,并根据软件模型协调质量控制和保证行动。Marouane Kessentini 已在 eBay 和 SEMA 等公司部署了行业级工具,这些工具旨在通过自动检测软件缺陷 [Man17] 并推荐重构解决方案来解决这些缺陷 [Ali18] 来减少技术债务问题。这项工作显示出巨大的前景。

Novotny argues that a new generation of tools will work in conjunction with a repository to create models at all necessary levels of abstraction, establish relationships between the various models, translate models at one level of abstraction to another level (e.g., translate a design model into source code), manage changes and versions, and coordinate quality control and assurance actions against the software models. Marouane Kessentini has deployed industry-grade tools at companies like eBay and SEMA that are designed to reduce technical debt problems by automatically detecting software defects [Man17] and recommending refactoring solutions to resolve them [Ali18]. This work is showing great promise.

除了完整的软件工程环境之外,解决从需求收集到设计/代码重构再到测试的所有问题的单点解决方案工具将继续发展并变得更加功能强大。在某些情况下,与通用工具相比,针对特定应用领域的建模和测试工具将提供更大的优势。Facebook 的 Mark Harman 团队宣布部署一种工具,可以自动设计测试用例并测试开发人员修复软件崩溃后的情况 [Als18],希望生产软件有一天能够自我修复。

In addition to complete software engineering environments, point-solution tools that address everything from requirements gathering to design/code refactoring to testing will continue to evolve and become more functionally capable. In some instances, modeling and testing tools targeted at a specific application domain will provide enhanced benefit when compared to their generic equivalents. Mark Harman’s group at Facebook has announced deployment of a tool that automatically designs test cases and tests developers fixes following software crashes [Als18] with the hope that production software may be able to repair itself someday.

29.7 总结

29.7 Summary

对软件工程技术产生影响的趋势通常来自业务、组织、市场和文化领域。这些“软趋势”可以指导研究方向以及研究结果所衍生的技术。人工智能和数据科学方法很可能将继续影响软件工程的各个方面。

The trends that have an effect on software engineering technology often come from business, organizational, market, and cultural arenas. These “soft trends” can guide the direction of research and the technology that is derived as a consequence of research. It is likely that artificial intelligence and data science methods will continue to impact all aspects of software engineering.

随着一项新技术的推出,它会经历一个并不总是能得到广泛采用的生命周期,尽管最初的期望很高。任何软件工程技术获得广泛采用的程度都与其解决软趋势和硬趋势所带来的问题的能力有关。数字个人助理和社交媒体似乎正在影响人们日常生活的许多方面的活动。随着它们的兴起,人们开始担心软件产品开发中安全和隐私的重要性。

As a new technology is introduced, it moves through a life cycle that does not always lead to widespread adoption, even though original expectations are high. The degree to which any software engineering technology gains widespread adoption is tied to its ability to address the problems posed by both soft and hard trends. Digital personal assistants and social media seem to be influencing the activities of individuals in many aspects of everyday life. With their rise have come concerns about the importance of both security and privacy in the development of software products.

软趋势——对连通性和协作、全球项目、知识转移、新兴经济体的影响以及人类文化本身的影响不断增长的需求——导致了一系列挑战,涵盖管理复杂性和紧急需求,到应对不断变化的环境。改变地理上分散的软件团队的人才结构。全球工程可能会继续存在。第601页

Soft trends—the growing need for connectivity and collaboration, global projects, knowledge transfer, the impact of emerging economies, and the influence of human culture itself—lead to a set of challenges that spans managing complexity and emergent requirements, to juggling an ever-changing talent mix among geographically dispersed software teams. Global engineering is likely here to stay.Page 601

硬趋势(技术变革的步伐不断加快)从软趋势中流出,影响软件的结构、流程的范围以及流程框架的特征化方式。协作开发、新形式的需求工程、基于模型和测试驱动的开发以及后现代设计将改变方法格局。工具环境将响应日益增长的通信和协作需求,同时集成可能改变当前软件工程任务性质的特定领域的单点解决方案。机器学习可能是自动化许多重要软件工程任务的一种方法。

Hard trends—the ever-accelerating pace of technology change—flow out of soft trends and affect the structure of the software and scope of the process and the manner in which a process framework is characterized. Collaborative development, new forms of requirements engineering, model-based and test-driven development, and postmodern design will change the methods landscape. Tools environments will respond to a growing need for communication and collaboration and at the same time integrate domain-specific point solutions that may change the nature of current software engineering tasks. Machine learning is likely to be one approach to automating many important software engineering tasks.

问题与思考点

Problems and Points to Ponder

29.1。获取马尔科姆·格拉德威尔 (Malcolm Gladwell) 的畅销书《引爆点》(可通过 Google 图书搜索获取),并讨论他的理论如何应用于新软件工程技术的采用。

29.1. Get a copy of the best-selling book The Tipping Point by Malcolm Gladwell (available via Google Book Search), and discuss how his theories apply to the adoption of new software engineering technologies.

29.2. 为什么开放世界软件对传统软件工程方法提出了挑战?

29.2. Why does open-world software present a challenge to conventional software engineering approaches?

29.3。查看 Gartner Group对新兴技术的炒作周期。选择一个知名的技术产品,并介绍一个简短的历史,说明它是如何沿着曲线发展的。选择另一种未遵循炒作曲线建议路径的知名科技产品。

29.3. Review the Gartner Group’s hype cycle for emerging technologies. Select a well-known technology product, and present a brief history that illustrates how it traveled along the curve. Select another well-known technology product that did not follow the path suggested by the hype curve.

29.4。什么是“软趋势”?

29.4. What is a “soft trend”?

29.5。您面临着一个极其复杂的问题,需要漫长的解决方案。您将如何解决复杂性并制定解决方案?

29.5. You’re faced with an extremely complex problem that will require a lengthy solution. How would you go about addressing the complexity and crafting a solution?

29.6。什么是“紧急需求”?为什么它们会给软件工程师带来挑战?

29.6. What are “emergent requirements,” and why do they present a challenge to software engineers?

29.7。选择一个开源开发项目(Linux 除外),并介绍其演变和相对成​​功的简要历史。

29.7. Select an open-source development effort (other than Linux), and present a brief history of its evolution and relative success.

29.8。描述您认为软件流程在未来十年将如何变化。

29.8. Describe how you think the software process will change over the next decade.

29.9。您位于洛杉矶,在一个全球软件工程团队工作。您和伦敦、孟买、香港和悉尼的同事必须为大型系统编辑 245 页的需求规范。第一遍编辑必须在三天内完成。描述可以帮助您有效协作的理想在线工具集。

29.9. You’re based in Los Angeles and are working on a global software engineering team. You and colleagues in London, Mumbai, Hong Kong, and Sydney must edit a 245-page requirements specification for a large system. The first editing pass must be completed in three days. Describe the ideal online tool set that would enable you to collaborate effectively.

29.10。用您自己的话描述模型驱动的软件开发。对测试驱动开发执行相同的操作。

29.10. Describe model-driven software development in your own words. Do the same for test-driven development.

1 Kurzweil [Kur05] 提出了一个合理的技术论证,预测到 2029 年将出现强大的人工智能(将通过图灵测试),并表明人类和机器的进化将在 2045 年开始融合。本书的绝大多数读者我们将活着看看这是否真的发生。

1 Kurzweil [Kur05] presents a reasoned technical argument that predicts a strong artificial intelligence (that will pass the Turing Test) by 2029 and suggests that the evolution of humans and machines will begin to merge by 2045. The vast majority of readers of this book will live to see whether this, in fact, takes place.

2供应方对市场采取“建造它,他们就会来”的方法。独特的技术被创造出来,消费者蜂拥而至——有时!

2 Supply side adopts a “build it and they will come” approach to markets. Unique technologies are created, and consumers flock to adopt them—sometimes!

3例如,现代笔记本电脑操作系统(例如 Linux、macOS 和 Windows)拥有 30 到 6000 万个 LOC。移动设备的操作系统软件可以超过 200 万个 LOC。

3 For example, modern laptop operating systems (e.g., Linux, macOS, and Windows) have between 30 and 60 million LOC. Operating system software for mobile devices can exceed 2 million LOC.

4事实上,这个“系统”实际上是一个系统系统——数百个可互操作的应用程序协同工作以实现某些总体目标,其中许多应用程序将基于云。

4 In reality, this “system” will actually be a system of systems—hundreds of interoperable applications working together to achieve some overall objective, and many will be cloud based.

5并非所有复杂系统都很大。相对较小的应用程序(例如,小于 100,000LOC)仍然可能非常复杂。

5 Not all complex systems are large. A relatively small application (say, less than 100,000LOC) can still be exceedingly complex.

6有关环境智能的有价值且相当详细的介绍,请访问 https://www.researchgate.net/publication/220737998_Ambient_Intelligence_Basic_Concepts_and_Applications。

6 A worthwhile and quite detailed introduction to ambient intelligence can be found at https://www.researchgate.net/publication/220737998_Ambient_Intelligence_Basic_Concepts_and_Applications.

7产品线软件是一组应用程序,由一组通用的可重用软件模块构建而成,旨在在创建新软件产品时轻松适应。

7 Product-line software is a set of application programs that are built from a common set of reusable software modules designed to be easily adaptable when creating in new software products.

8还使用术语模型驱动工程(MDE)。

8 The term model-driven engineering (MDE) is also used.

9遗传算法可用于生成优化和搜索问题的高质量解决方案,方法是依靠仿生算子(例如变异、交叉和选择)从潜在解决方案群体中演化出潜在解决方案。

9 Genetic algorithms can be used to generate high-quality solutions to optimization and search problems by relying on bio-inspired operators such as mutation, crossover, and selection to evolve potential solutions from a population of potential solutions.

10回想一下,极限编程(第 3 章)强调这种方法是其敏捷过程模型的一部分。

10 Recall that Extreme Programming (Chapter 3) emphasizes this approach as part of its agile process model.

11还使用术语集成开发环境(IDE)。

11 The term integrated development environment (IDE) is also used.

第602页

Page 602

章节

chapter

30结论性意见

30 Concluding Comments

在本章之前的 29 章中,我们探索了软件工程的过程,其中包括管理程序和技术方法、基本概念和原则、专业技术、以人为本的活动和任务,这些活动和任务适合自动化、纸质和-铅笔符号和软件工具。我们认为,衡量、纪律以及对敏捷性和质量的压倒性关注将带来满足客户需求的软件、可靠的软件、可支持的软件、更好的软件。然而,我们从未承诺过软件工程是万能的。

In the 29 chapters that have preceded this one, we’ve explored a process for software engineering that encompasses management procedures and technical methods, basic concepts and principles, specialized techniques, people-oriented activities and tasks that are amenable to automation, paper-and-pencil notation, and software tools. We have argued that measurement, discipline, and an overriding focus on agility and quality will result in software that meets the customer’s needs, software that is reliable, software that is supportable, software that is better. Yet, we have never promised that software engineering is a panacea.

第603页对于每个软件专业人员和每个构建基于计算机的系统的公司来说,软件和系统技术仍然是一个挑战。尽管马克思·霍珀[Hop90]以二十世纪的观点写下这些话,但他准确地描述了当前的事态:

Page 603Software and systems technologies remain a challenge for every software professional and every company that builds computer-based systems. Although he wrote these words with a twentieth-century outlook, Max Hopper [Hop90] accurately describes the current state of affairs:

由于信息技术的变化变得如此迅速和无情,而落后的后果又是不可逆转的,企业要么掌握技术,要么消亡。。。将其视为一台技术跑步机。公司必须越来越努力才能保持原状。

Because changes in information technology are becoming so rapid and unforgiving, and the consequences of falling behind are so irreversible, companies will either master the technology or die . . . Think of it as a technology treadmill. Companies will have to run harder and harder just to stay in place.

软件工程技术的变化确实是“快速且无情的”,但同时真正的进展往往相当缓慢。当决定采用新的流程、方法或工具时;进行必要的培训以了解其应用;并将该技术引入软件开发文化中,更新(甚至更好)的东西出现了,并且该过程重新开始。

Changes in software engineering technology are indeed “rapid and unforgiving,” but at the same time real progress is often quite slow. By the time a decision is made to adopt a new process, method, or tool; conduct the training necessary to understand its application; and introduce the technology into the software development culture, something newer (and even better) has come along, and the process begins anew.

多年来我们在这一领域学到的一件事是,软件工程从业者具有“时尚意识”。前方的道路将布满令人兴奋的新技术(最新时尚)的残骸,但这些技术从未真正成功(尽管有大肆宣传)。它将由更温和的技术塑造,以某种方式改变大道的方向和宽度。我们在第 29 章中讨论了其中的一些内容。

One thing we’ve learned over our years in this field is that software engineering practitioners are “fashion conscious.” The road ahead will be littered with the carcasses of exciting new technologies (the latest fashion) that never really made it (despite the hype). It will be shaped by more modest technologies that somehow modify the direction and width of the thoroughfare. We discussed a few of those in Chapter 29.

在这一章的结论中,我们将采取更广阔的视野,从更哲学的角度思考我们已经去过的地方以及我们要去的地方。

In this concluding chapter, we’ll take a broader view and consider where we’ve been and where we’re going from a more philosophical perspective.

30.1 软件的重要性——回顾

30.1 The Importance of Software—Revisited

计算机软件的重要性可以通过多种方式来表述。在第一章中,软件被描述为差异化因素。软件提供的功能使产品、系统和服务脱颖而出,并提供市场竞争优势。但软件不仅仅是一个差异化因素。作为一个整体,软件工程工作产品生成任何个人、企业或政府都可以获得的最重要的商品——信息。

The importance of computer software can be stated in many ways. In Chapter 1, software was characterized as a differentiator. The function delivered by software differentiates products, systems, and services and provides competitive advantage in the marketplace. But software is more than a differentiator. When taken as a whole, software engineering work products generate the most important commodity that any individual, business, or government can acquire—information.

第 29 章中,我们简要讨论了开放世界计算——一种从根本上改变我们对计算机的看法、我们用计算机做的事情(以及它们为我们做的事情)以及我们对信息作为指南、商品的看法的技术。和必需品。我们还指出,支持开放世界计算所需的软件将为软件工程师带来巨大的新挑战。但更重要的是,计算机软件的日益普及将为整个社会带来更加严峻的挑战。每当一项技术产生广泛影响时——这种影响可以拯救生命或危及生命、建立企业或摧毁企业、通知政府领导人或误导他们——就必须谨慎处理。

In Chapter 29, we briefly discussed open-world computing—a technology that is fundamentally changing our perception of computers, the things that we do with them (and they do for us), and our perception of information as a guide, a commodity, and a necessity. We also noted that software required to support open-world computing will present dramatic new challenges for software engineers. But far more important, the growing pervasiveness of computer software will present even more dramatic challenges for society as a whole. Whenever a technology has a broad impact—an impact that can save lives or endanger them, build businesses or destroy them, inform government leaders or mislead them—it must be handled with care.

30.2 人和他们构建系统的方式

30.2 People and the Way They Build Systems

高科技系统所需的软件逐年变得更加复杂,最终程序的大小也成比例增加。如果不是因为一个简单的事实,“平均”项目规模的快速增长不会给我们带来什么问题:随着项目规模的增加,必须参与该项目的人数也必须增加。

The software required for high-technology systems becomes more complex with each passing year, and the size of resultant programs increases proportionally. The rapid growth in the size of the “average” program would present us with few problems if it wasn’t for one simple fact: As program size increases, the number of people who must work on the program must also increase.

第604页经验表明,随着软件项目团队人数的增加,团队的整体生产力可能会受到影响。解决这个问题的一种方法是创建多个软件工程团队,从而将人员划分为单独的工作组。然而,随着软件工程团队数量的增长,他们之间的沟通变得困难且耗时。更糟糕的是,(个人或团队之间)的沟通往往效率低下,也就是说,花费太多时间来传输太少的信息内容,而且很多时候,重要的信息“落入了裂缝”。

Page 604Experience indicates that as the number of people on a software project team increases, the overall productivity of the group may suffer. One way around this problem is to create a number of software engineering teams, thereby compartmentalizing people into individual working groups. However, as the number of software engineering teams grows, communication between them becomes as difficult and time consuming. Worse, communication (between individuals or teams) tends to be inefficient—that is, too much time is spent transferring too little information content, and all too often, important information “falls into the cracks.”

如果软件工程社区要有效地解决沟通困境,那么软件工程师的未来之路必须包括个人和团队彼此沟通方式的彻底改变。在第 27 章中,我们讨论了社交媒体在支持软件发布管理中的使用,这可能会极大地改进开发人员和客户的沟通方式。

If the software engineering community is to deal effectively with the communication dilemma, the road ahead for software engineers must include radical changes in the way individuals and teams communicate with one another. In Chapter 27, we discussed the use of social media in supporting software release management that may provide dramatic improvements in the ways developers and customers communicate.

最后,沟通是知识的传递,而知识的获取(和传递)正在发生深刻的变化。随着搜索引擎变得越来越复杂,社交网络和众包演变为开发工具,移动应用程序提供更好的协同作用,知识转移的速度和质量将呈指数级增长。

Finally, communication is the transfer of knowledge, and the acquisition (and transfer) of knowledge is changing in profound ways. As search engines become increasingly sophisticated, social networking and crowd-sourcing morph into development tools, and mobile applications provide better synergy, the speed and quality of knowledge transfer will grow exponentially.

如果以过去的历史为鉴的话,可以公平地说,人本身不会改变。然而,他们的沟通方式、他们的工作环境、他们获取知识的方式、他们使用的方法和工具、他们应用的规则,以及因此软件开发的整体文化都将发生变化。重要甚至深刻的方式。

If past history is any indication, it is fair to say that people themselves will not change. However, the ways in which they communicate, the environment in which they work, the manner in which they acquire knowledge, the methods and tools that they use, the discipline that they apply, and therefore, the overall culture for software development will change in significant and even profound ways.

第605页

Page 605

30.3 知识发现

30.3 Knowledge Discovery

在计算的历史上,用于描述为商业社区执行的软件开发工作的术语发生了微妙的转变。五十年前,数据处理一词是描述计算机在商业环境中的使用的常用短语。如今,数据处理已经让位于另一个词——信息技术——它暗示着同样的事情,但焦点却发生了微妙的转变。重点不仅仅是处理大量数据,而是从这些数据中提取有意义的信息。显然,这始终是意图,但术语的转变反映了管理理念的更重要的转变。

Over the history of computing, a subtle transition has occurred in the terminology that is used to describe software development work performed for the business community. Fifty years ago, the term data processing was the operative phrase for describing the use of computers in a business context. Today, data processing has given way to another phrase—information technology—that implies the same thing but presents a subtle shift in focus. The emphasis is not merely to process large quantities of data but rather to extract meaningful information from this data. Obviously, this was always the intent, but the shift in terminology reflects a far more important shift in management philosophy.

如今,当讨论软件应用程序时,数据、信息内容等词会反复出现。我们在许多人工智能应用中都会遇到知识这个词。几乎没有人在软件应用程序的背景下讨论智慧。

When software applications are discussed today, the words data, information, and content occur repeatedly. We encounter the word knowledge in many artificial intelligence applications. Virtually no one discusses wisdom in the context of software applications.

数据是原始信息——必须经过处理才能有意义的事实集合。信息是通过在给定上下文中关联事实而得出的。知识将在一种上下文中获得的信息与在不同上下文中获得的其他信息联系起来。最后,当从不同的知识中推导出普遍原则时,就会产生智慧。

Data is raw information—collections of facts that must be processed to be meaningful. Information is derived by associating facts within a given context. Knowledge relates information obtained in one context with other information obtained in a different context. Finally, wisdom occurs when generalized principles are derived from disparate bits of knowledge.

迄今为止,绝大多数软件都是为了处理数据或信息而构建的。软件工程师现在同样关注处理知识的系统。1收集的各种相关和不相关主题的信息相互关联,形成我们称之为知识的事实体系。关键是我们能够将来自各种不同来源的信息关联起来,这些信息可能没有任何明显的联系,并以一种为我们提供一些独特好处的方式将其组合起来。2

To date, the vast majority of all software has been built to process data or information. Software engineers are now equally concerned with systems that process knowledge.1 Information collected on a variety of related and unrelated topics is connected to form a body of facts that we call knowledge. The key is our ability to associate information from a variety of different sources that may not have any obvious connection and combine it in a way that provides us with some distinct benefit.2

为了说明从数据到知识的进展,请考虑人口普查数据,该数据表明 1996 年美国的出生率为 490 万。这个数字代表一个数据值。将这一数据与过去 40 年的出生率联系起来,我们可以得出一条有用的信息:20 世纪 50 年代和 60 年代初的婴儿潮一代为在育龄结束前生孩子而做出了最后的努力。此外,X 世代开始了生育年龄。然后,人口普查数据可以与其他看似无关的信息联系起来,例如,当前将在未来十年内退休的小学教师人数、获得中小学教育学位的大学生人数以及压力要求政治家压低税收,从而限制教师工资的增长。

To illustrate the progression from data to knowledge, consider census data indicating that the birthrate in 1996 in the United States was 4.9 million. This number represents a data value. Relating this piece of data with birthrates for the preceding 40 years, we can derive a useful piece of information—aging baby boomers of the 1950s and early 1960s made a last-gasp effort to have children prior to the end of their child-bearing years. In addition, gen-Xers began their childbearing years. The census data can then be connected to other seemingly unrelated pieces of information, for example, the current number of elementary school teachers who will retire during the next decade, the number of college students graduating with degrees in primary and secondary education, and the pressure on politicians to hold down taxes and therefore limit pay increases for teachers.

所有这些信息可以组合起来形成知识的表示——二十世纪初美国的教育系统将面临巨大的压力,并且这种压力将持续数十年。利用这些知识,可能会出现商机。可能存在开发比当前方法更有效且成本更低的新学习模式的重大机会。

All these pieces of information can be combined to formulate a representation of knowledge—there will be significant pressure on the education system in the United States in the early twenty-first century, and this pressure will continue for a number of decades. Using this knowledge, a business opportunity may emerge. There may be significant opportunity to develop new modes of learning that are more effective and less costly than current approaches.

第606页软件的未来之路通向发现和处理知识的系统。我们使用计算机处理数据已有 70 多年的历史,提取信息也已有三十多年的历史。软件工程社区面临的最重大挑战之一是构建能够迈出下一步的系统,即以实用且有益的方式从数据和信息中提取知识的系统。知识发现是一个跨学科领域,专注于从数据中提取有用关系的方法。

Page 606The road ahead for software leads to systems that both discover and process knowledge. We have been processing data using computers for more than 70 years and extracting information for more than three decades. One of the most significant challenges facing the software engineering community is to build systems that take the next step along the spectrum—systems that extract knowledge from data and information in a way that is practical and beneficial. Knowledge discovery is an interdisciplinary area focusing upon methodologies for extracting useful relationships from data.

Mark Harman(现任 Facebook 软件工程研究经理)是最早认识到使用数据挖掘和机器学习来解决困难的软件工程问题的价值的人之一 [Har12b]。多个公共软件工程数据存储库(例如Bugzilla、GitHub、SourceForge )的可用性使得使用基于搜索的软件工程技术来发现对软件开发工件和流程的见解成为可能 [Dye15] [Gup15]。这不是一件容易的任务,并且表明可能需要将数据科学家纳入大型软件工程项目的成员 [Kim16b]。在挖掘公共存储库时发现的知识可能会建议从事小型专有项目的软件工程师进行实践改进,或者可能产生可应用于他们自己的软件工程数据存储库的技术。

Mark Harman (currently Facebook’s manager for software engineering research) was one of the first people to recognize the value of using data mining and machine learning to solve difficult software engineering problems [Har12b]. The availability of several public software engineering data repositories (e.g., Bugzilla, GitHub, SourceForge) make it possible to use search-based software engineering techniques to discover insights into software development artifacts and processes [Dye15] [Gup15]. This is not an easy task and suggests that it may be desirable to include data scientists as members of large software engineering projects [Kim16b]. The knowledge discovered while mining public repositories may suggest practice improvements to software engineers working on smaller proprietary projects or may yield techniques that can be applied on their own software engineering data repositories.

机器学习已应用于软件工程的许多领域,从行为提取、设计模式识别、程序生成、测试用例生成和缺陷检测[Mei18]。如果没有大量的软件工程数据和领域专家来帮助塑造机器学习的概念,这项工作就无法完成。遗传算法3利用自动搜索,并且可用于通过启发式组合现有软件产品和过程的元素来开发改进的软件产品或过程。遗传学已被用来提高软件的各种属性性能,例如执行时间、内存消耗以及缺陷修复和现有系统功能扩展 [Pet18]。

Machine learning has been used in many areas of software engineering ranging from behavior extraction, design pattern recognition, program generation, test-case generation, and defect detection [Mei18]. This work cannot be done without access to large sets of software engineering data and access to domain experts to help shape the concepts learned by machines. Genetic algorithms3 make use of automated search and can be used to grow an improved software product or process by heuristically combining elements of existing software products and processes. Genetics have been used to improve software performance for a diverse set of properties such as execution time, memory consumption, as well as defect repair and existing system functionality extensions [Pet18].

智能软件工程正在成为结合人工智能(AI)和软件工程的学术研究领域。智能软件工程技术探索软件工程解决方案,以提高人工智能软件开发的生产力和人工智能软件的可靠性。它还试图解决尝试自动化软件工程流程时遇到的一些问题[Xie18]。随着人工智能技术变得更加强大和易于使用,它们越来越多地被部署为现代软件系统的关键组件。虽然这使得产品的创建能够更好地适应用户需求,但它也给软件工程师带来了额外的问题,并使公司面临新的风险[Fel18]。

Intelligent software engineering is emerging as an academic area of study that combines artificial intelligence (AI) and software engineering. Intelligent software engineering techniques explore software engineering solutions to improve the productivity of developing AI software and the dependability of AI software. It also seeks to address some of the problems encountered when attempting to automate software engineering processes [Xie18]. As AI techniques become more powerful and easier to use, they are increasingly deployed as key components of modern software systems. Although this allows the creation of products better able to adapt to user needs, it also creates additional problems for software engineers and exposes companies to new risks [Fel18].

30.4 长远眼光

30.4 The Long View

第 30.3 节中,我们建议未来的道路通向“发现知识”的系统。但一般计算和特别是基于软件的系统的未来可能会导致意义更为深远的事件。第607页

In Section 30.3, we suggested that the road ahead leads to systems that “discover knowledge.” But the future of computing in general and software-based systems in particular may lead to events that are considerably more profound.Page 607

Ray Kurzweil [Kur05] 在一本引人入胜的书中指出,我们已经到了这样一个时代:“技术变革的步伐将如此之快,其影响如此之深,人类的生活将发生了不可逆转的转变。” Kurzweil 4提出了一个令人信服的论点,即我们目前正处于指数​​增长曲线的“拐点”,这将导致未来几十年计算能力的巨大增长。当与纳米技术、遗传学和机器人技术等方面的进步相结合时,我们可能会在本世纪中叶迎来一个时代,那时人类(正如我们今天所知道的)和机器之间的区别开始变得模糊——人类进化加速的时代(对某些人来说)既令人恐惧又(对另一些人)令人惊叹的方式。

In a fascinating book that is must reading for every person involved in computing technologies, Ray Kurzweil [Kur05] suggests that we have reached a time when “the pace of technological change will be so rapid, its impact so deep, that human life will be irreversibly transformed.” Kurzweil4 makes a compelling argument that we are currently at the “knee” of an exponential growth curve that will lead to enormous increases in computing capacity over the next few decades. When coupled with equivalent advances in nanotechnology, genetics, and robotics, we may approach a time in the middle part of this century when the distinction between humans (as we know them today) and machines begins to blur—a time when human evolution accelerates in ways that are both frightening (to some) and spectacular (to others).

Kurzweil 认为,在未来十年的某个时候,计算能力和必要的软件将足以模拟人脑的各个方面,包括所有物理连接、模拟过程和化学覆盖 [Kur13]。当这种情况发生时,人类将迈出实现“强人工智能”的第一步,从而实现真正思考的机器(使用当今该词的传统用法)。但会有根本性的区别。人脑过程极其复杂,与外部非正式来源的联系非常松散。即使与当今的计算技术相比,它们的计算速度也很慢。当完全模拟人脑时,“思想”的发生速度将比人类大脑快数千倍,并与海量信息紧密相连(将当今的网络视为一个原始的例子)。结果是。。。出色地 。。。如此奇幻,最好由库兹韦尔来描述。

Kurzweil argues that sometime in the coming decade computing capacity and the requisite software will be sufficient to model every aspect of the human brain, including all the physical connections, analog processes, and chemical overlays [Kur13]. When this occurs, human beings will take the first step toward achieving “strong AI (artificial intelligence),” and as a consequence, machines that truly do think (using today’s conventional use of the word). But there will be a fundamental difference. Human brain processes are exceedingly complex and only loosely connected to external informal sources. They are also computationally slow, even in comparison to today’s computing technology. When full human brain emulation occurs, “thought” will occur at speeds thousands of times more rapid than its human counterpart with intimate connections to a sea of information (think of the present-day Web as a primitive example). The result is . . . well . . . so fantastical that it’s best left to Kurzweil to describe.

值得注意的是,并不是所有人都认为库兹韦尔描述的未来是一件好事。Sun Microsystems 的创始人之一 Bill Joy [Joy00] 在一篇现在著名的题为“未来不需要我们”的文章中认为,“机器人、基因工程和纳米技术正威胁着人类成为濒临灭绝的物种。 ” 他的论点以及比尔·盖茨、埃隆·马斯克和已故史蒂文·霍金等名人的评论预测了潜在的技术反乌托邦,这与库兹韦尔预测的乌托邦未来形成了对立。两者都应该得到认真考虑,因为软件工程师在定义人类的长期愿景方面发挥着主导作用。

It’s important to note that not everyone believes that the future Kurzweil describes is a good thing. In a now-famous essay titled “The Future Doesn’t Need Us,” Bill Joy [Joy00], one of the founders of Sun Microsystems, argues that “robotics, genetic engineering, and nanotech are threatening to make humans an endangered species.” His arguments, along with commentary by luminaries such Bill Gates, Elon Musk, and the late Steven Hawking, predicting a potential technology dystopia represent a counterpoint to Kurzweil’s predicted utopian future. Both should be seriously considered as software engineers take one of the lead roles in defining the long view for the human race.

30.5 软件工程师的责任

30.5 The Software Engineer’s Responsibility

软件工程已经发展成为一个受人尊敬的、全球性的职业。作为专业人士,软件工程师应该遵守指导他们所做的工作和生产的产品的道德准则。ACM/IEEE-CS 联合工作组制定了软件工程道德和专业实践准则(5.1 版)。代码 [ACM12] 指出:第608页

Software engineering has evolved into a respected, worldwide profession. As professionals, software engineers should abide by a code of ethics that guides the work they do and the products they produce. An ACM/IEEE-CS Joint Task Force has produced a Software Engineering Code of Ethics and Professional Practices (Version 5.1). The code [ACM12] states:Page 608

软件工程师应致力于使软件的分析、规范、设计、开发、测试和维护成为有益且受人尊敬的职业。根据对公众健康、安全和福利的承诺,软件工程师应遵守以下八项原则:

Software engineers shall commit themselves to making the analysis, specification, design, development, testing, and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

  1. 公共——软件工程师的行为应符合公共利益。

  2. PUBLIC—Software engineers shall act consistently with the public interest.

  3. 客户和雇主——软件工程师的行为方式应符合客户和雇主的最大利益,并符合公共利益。

  4. CLIENT AND EMPLOYER—Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

  5. 产品——软件工程师应确保他们的产品和相关修改符合尽可能的最高专业标准。

  6. PRODUCT—Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

  7. 判断——软件工程师应保持其专业判断的完整性和独立性。

  8. JUDGMENT—Software engineers shall maintain integrity and independence in their professional judgment.

  9. 管理——软件工程经理和领导者应赞同并提倡采用道德方法来管理软件开发和维护。

  10. MANAGEMENT—Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

  11. 职业——软件工程师应促进符合公共利益的职业诚信和声誉。

  12. PROFESSION—Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

  13. 同事——软件工程师应该公平对待并支持他们的同事。

  14. COLLEAGUES—Software engineers shall be fair to and supportive of their colleagues.

  15. 自我——软件工程师应参与其职业实践的终身学习,并应促进职业实践的道德方法。

  16. SELF—Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

尽管这八个原则中的每一个都同样重要,但出现了一个压倒一切的主题:软件工程师应该为公共利益而工作。在个人层面上,软件工程师应该遵守以下规则:

Although each of these eight principles is equally important, an overriding theme appears: A software engineer should work in the public interest. On a personal level, a software engineer should abide by the following rules:

  • 切勿为了个人利益而窃取数据。

  • Never steal data for personal gain.

  • 切勿分发或出售您在软件项目工作中获得的专有信息。

  • Never distribute or sell proprietary information obtained as part of your work on a software project.

  • 切勿恶意破坏或修改他人的程序、文件或数据。

  • Never maliciously destroy or modify another person’s programs, files, or data.

  • 切勿侵犯个人、团体或组织的隐私。

  • Never violate the privacy of an individual, a group, or an organization.

  • 切勿为了体育或盈利而侵入系统。

  • Never hack into a system for sport or profit.

  • 切勿创建或传播计算机病毒或蠕虫。

  • Never create or promulgate a computer virus or worm.

  • 切勿使用计算机技术来促进歧视或骚扰。

  • Never use computing technology to facilitate discrimination or harassment.

在过去的十年中,软件行业的某些成员一直在游说保护性立法,以(1)允许公司在不披露已知缺陷的情况下发布软件,(2)免除开发人员对这些已知缺陷造成的任何损害的责任,(3)限制其他人未经原始开发人员许可不得披露缺陷,(4) 允许在产品中合并“自助”软件,该软件可以禁用(通过远程命令)产品的操作,以及 (5) 免除软件开发人员如果该软件被第三方禁用,则可以“自助”免受损害。

Over the past decade, certain members of the software industry have lobbied for protective legislation that (1) allows companies to release software without disclosing known defects, (2) exempts developers from liability for any damages resulting from these known defects, (3) constrains others from disclosing defects without permission from the original developer, (4) allows the incorporation of “self-help” software within a product that can disable (via remote command) the operation of the product, and (5) exempts developers of software with “self-help” from damages should the software be disabled by a third party.

第609页与所有立法一样,辩论通常集中在政治问题上,而不是技术问题上。然而,许多人(包括我们)认为,保护性立法如果起草不当,就会间接免除软件工程师生产高质量软件的责任,从而与软件工程道德准则发生冲突。鉴于2018年发生的大规模社交媒体数据泄露事件,存储大量机密客户数据的公司将需要加强安全保护。

Page 609Like all legislation, debate often centers on issues that are political, not technological. However, many people (including us) feel that protective legislation, if improperly drafted, conflicts with the software engineering code of ethics by indirectly exempting software engineers from their responsibility to produce high-quality software. Given the sizeable social media data breaches that occurred in 2018, there will be more demands for enhanced security protections by companies storing large amounts of confidential customer data.

自主系统决策能力的不断增强以及人工智能对我们日常生活的影响使我们想要考虑这些系统中嵌入的价值[Vak18]。软件工程行业需要研究衡量搜索算法和社交网络中偏差的方法 [Pit18]。修订后的 ACM 道德和职业行为准则 [ACM18] 采用了多项新原则,解决特定计算技术中的问题,例如人工智能、机器学习和自主机器做出具有道德意义的重大决策 [Got18]。ACM 和 IEEE 很可能会考虑修改其软件工程道德准则以反映这些新领域。

The growing decision-making capabilities of autonomous systems and the influence of AI in our daily lives make us want to consider the values embedded in these systems [Vak18]. The software engineering profession needs to examine ways to measure bias in search algorithms and social networks [Pit18]. The revised ACM Code of Ethics and Professional Conduct [ACM18] adopts several new principles that address issues in specific computing technologies such as AI, machine learning, and autonomous machines making ethically significant decisions [Got18]. It is likely that the ACM and IEEE will consider revising their Software Engineering Code of Ethics to reflect these new areas as well.

30.6 RSP 的最终评论

30.6 A Final Comment from RSP

自本书第一版的编写工作开始以来,已经过去了近四十年。我[RSP]仍然记得,作为一名年轻教授,我坐在办公桌前,为一本很少有人关心、真正理解的主题的书撰写手稿。我记得出版商的拒绝信,他们(礼貌但坚定地)辩称,关于“软件工程”的书永远不会有市场。幸运的是,麦格劳-希尔决定尝试一下,5,剩下的,正如他们所说,已经成为历史了。

It has been almost four decades since work on the first edition of this book began. I [RSP] can still recall sitting at my desk as a young professor, writing the manuscript for a book on a subject that few people cared about and even fewer really understood. I remember the rejection letters from publishers, who argued (politely, but firmly) that there would never be a market for a book on “software engineering.” Luckily, McGraw-Hill decided to try it,5 and the rest, as they say, is history.

自第一版以来,本书在范围、篇幅、风格和内容上都发生了巨大的变化。与软件工程一样,它经过多年的发展和成熟。

Since the first edition, this book has changed dramatically—in scope, in size, in style, and in content. Like software engineering, it has grown and matured over the years.

计算机软件开发的工程方法现在已成为传统观点。关于“正确范例”、敏捷性的重要性、自动化程度和最有效方法的争论仍在继续。但软件工程的基本原理现在已被整个行业所接受。那么,为什么我们直到最近才看到它们的广泛采用呢?

An engineering approach to the development of computer software is now conventional wisdom. Debate continues on the “right paradigm,” the importance of agility, the degree of automation, and the most effective methods. But the underlying principles of software engineering are now accepted throughout the industry. Why, then, have we seen their broad adoption only recently?

我认为,答案在于技术转型的困难以及随之而来的文化变革。尽管我们大多数人都意识到软件工程学科的必要性,但我们仍与过去实践的惯性作斗争,并面临新的应用程序领域(以及在其中工作的开发人员),这些领域似乎准备重复过去的错误。为了简化过渡,我们需要很多东西——敏捷、适应性强且合理的软件流程;更有效的方法;更强大的工具;从业者更好的接受度和管理者的支持;以及不小的教育。

The answer, I think, lies in the difficulty of technology transition and the cultural change that accompanies it. Even though most of us appreciate the need for an engineering discipline for software, we struggle against the inertia of past practice and face new application domains (and the developers who work in them) that appear ready to repeat the mistakes of the past. To ease the transition, we need many things—an agile, adaptable, and sensible software process; more effective methods; more powerful tools; better acceptance by practitioners and support from managers; and no small dose of education.

您可能不同意本书中描述的每一种方法。有些技术和观点存在争议;其他的必须进行调整才能在不同的软件开发环境中正常工作。然而,我真诚地希望《软件工程:从业者的方法》能够描述我们面临的问题,展示软件工程概念的力量,并提供方法和工具的框架。第610页

You may not agree with every approach described in this book. Some of the techniques and opinions are controversial; others must be tuned to work well in different software development environments. It is my sincere hope, however, that Software Engineering: A Practitioner’s Approach has delineated the problems we face, demonstrated the strength of software engineering concepts, and provided a framework of methods and tools.Page 610

进入二十一世纪,软件仍然是世界舞台上最重要的产品和最重要的产业。它的影响和重要性已经取得了长足的进步。然而,新一代软件开发人员必须应对前几代人面临的许多相同挑战。让我们希望迎接挑战的人们——软件工程师——能够拥有开发改善人类状况的系统的智慧。

As we move further into the twenty-first century, software continues to be the most important product and the most important industry on the world stage. Its impact and importance have come a long, long way. And yet, a new generation of software developers must meet many of the same challenges faced by earlier generations. Let us hope that the people who meet the challenge—software engineers—will have the wisdom to develop systems that improve the human condition.

1数据挖掘和数据仓库技术的快速增长反映了这种增长趋势。

1 The rapid growth of data mining and data warehousing technologies reflect this growing trend.

2语义 Web (Web 2.0) 允许创建“混搭”,这可以提供实现此目的的简便机制。

2 The semantic Web (Web 2.0) allows the creation of “mashups” that may provide a facile mechanism for achieving this.

3遗传算法用于搜索计算机生成的问题潜在解决方案群体,旨在找到最佳解决方案,同时保持候选解决方案集的多样性。

3 Genetic algorithms are used to search a population of computer-generated potential solutions to a problem with the intent of finding the best solution while maintaining the diversity of the set of candidate solutions.

4值得注意的是,库兹韦尔并不是一位普通的科幻小说作家,也不是一位没有作品集的未来学家。他是一位严肃的技术专家(来自维基百科)“一直是光学字符识别 (OCR)、文本到语音合成、语音识别技术和电子键盘乐器领域的先驱”。

4 It’s important to note that Kurzweil is not a run-of-the mill science fiction writer or a futurist without portfolio. He is a serious technologist who (from Wikipedia) “has been a pioneer in the fields of optical character recognition (OCR), text-to-speech synthesis, speech recognition technology, and electronic keyboard instruments.”

5事实上,这应该归功于 Peter Freeman 和 Eric Munson,他们让 McGraw-Hill 相信这本书值得一试,并且在发行了 300 万份后,可以公平地说他们做出了一个很好的决定。

5 Actually, credit should go to Peter Freeman and Eric Munson, who convinced McGraw-Hill that it was worth a shot, and 3 million copies later, it’s fair to say they made a good decision.

第611页

Page 611

附录

Appendix

1UML 简介1

1 An Introduction to UML1

统一建模语言(UML)是“一种用于编写软件蓝图的标准语言。UML 可用于可视化、指定、构建和记录软件密集型系统的工件”[Boo05]。换句话说,就像建筑建筑师创建建筑公司使用的蓝图一样,软件架构师创建 UML 图来帮助软件开发人员构建软件。如果您了解 UML 词汇(图表的图形元素及其含义),您可以更轻松地理解和指定系统并向其他人解释该系统的设计。

The Unified Modeling Language (UML) is “a standard language for writing software blueprints. UML may be used to visualize, specify, construct, and document the artifacts of a software-intensive system” [Boo05]. In other words, just as building architects create blueprints to be used by a construction company, software architects create UML diagrams to help software developers build the software. If you understand the vocabulary of UML (the diagrams’ pictorial elements and their meanings), you can much more easily understand and specify a system and explain the design of that system to others.

Grady Booch、Jim Rumbaugh 和 Ivar Jacobson 在 20 世纪 90 年代中期开发了 UML,并得到了软件开发社区的大量反馈。UML 合并了当时软件行业使用的许多相互竞争的建模符号。1997 年,UML 1.0 被提交给对象管理组,这是一个参与维护计算机行业使用的规范的非营利性联盟。UML 1.0 修订为 UML 1.1,并于当年晚些时候被采用。当前标准是 UML 2.5.1 2,现已成为 ISO 标准。由于此标准是新标准,因此许多较旧的参考文献(例如 [Gam95])不使用 UML 表示法。

Grady Booch, Jim Rumbaugh, and Ivar Jacobson developed UML in the mid-1990s with much feedback from the software development community. UML merged a number of competing modeling notations that were in use by the software industry at the time. In 1997, UML 1.0 was submitted to the Object Management Group, a nonprofit consortium involved in maintaining specifications for use by the computer industry. UML 1.0 was revised to UML 1.1 and adopted later that year. The current standard is UML 2.5.12 and is now an ISO standard. Because this standard is new, many older references, such as [Gam95] do not use UML notation.

UML 2.5.1 提供了 13 种不同的图表用于软件建模。在本附录中,我们将仅讨论类、部署、用例、序列、 通信、活动状态 图。这些图表在本版《软件工程:从业者的方法》中使用。

UML 2.5.1 provides 13 different diagrams for use in software modeling. In this appendix, we will discuss only class, deployment, use-case, sequence, communication, activity, and state diagrams. These diagrams are used in this edition of Software Engineering: A Practitioner’s Approach.

您应该注意到 UML 图中有许多可选功能。UML 语言提供了这些(有时是晦涩难懂的)选项,以便您可以表达系统的所有重要方面。同时,您可以灵活地抑制图表中与建模方面不相关的部分,以避免图表中出现不相关的细节。因此,省略某项功能并不意味着该功能不存在;这可能意味着该功能被抑制。在本附录中,我们不会详尽介绍 UML 图的所有功能。相反,我们关注标准选项,尤其是本书中使用的那些选项。

You should note that there are many optional features in UML diagrams. The UML language provides these (sometimes arcane) options so that you can express all the important aspects of a system. At the same time, you have the flexibility to suppress those parts of the diagram that are not relevant to the aspect being modeled to avoid cluttering the diagram with irrelevant details. Therefore, the omission of a feature does not mean that the feature is absent; it may mean that the feature was suppressed. In this appendix, we will not present exhaustive coverage of all the features of the UML diagrams. Instead, we focus on the standard options, especially those options that have been used in this book.

第612页

Page 612

_ _

Class Diagrams

为了对类进行建模,包括它们的属性、操作以及它们与其他类的关系和关联,UML 提供了 图。类图提供系统的静态或结构视图。它没有显示图中类的对象之间通信的动态性质。

To model classes, including their attributes, operations, and their relationships and associations with other classes, UML provides a class diagram. A class diagram provides a static or structural view of the system. It does not show the dynamic nature of the communications between the objects of the classes in the diagram.

类图的主要元素是框,它们是用于表示类和接口的图标。每个盒子都分为水平部分。顶部包含类的名称。中间部分列出了类的属性。属性可以是类可以从其实例变量计算出的值,也可以是类可以从组成该类的其他对象获取的值。例如,一个对象可能总是知道当前时间,并且能够在您询问时将其返回给您,在这种情况下,将当前时间列为该类对象的属性是合适的。但是,该对象很可能不会将该时间存储在其实例变量之一中,因为它需要不断更新该字段。相反,该对象可能会在请求时间时计算当前时间(例如,通过咨询其他类的对象)。类图的第三部分包含类的操作或行为。操作指类的对象可以执行的操作。它通常作为类的方法来实现。

The main elements of a class diagram are boxes, which are the icons used to represent classes and interfaces. Each box is divided into horizontal parts. The top part contains the name of the class. The middle section lists the attributes of the class. Attributes can be values that the class can compute from its instance variables or values that the class can get from other objects of which it is composed. For example, an object might always know the current time and be able to return it to you whenever you ask, in which case it would be appropriate to list the current time as an attribute of that class of objects. However, the object would most likely not have that time stored in one of its instance variables, because it would need to continually update that field. Instead, the object would likely compute the current time (e.g., through consultation with objects of other classes) at the moment when the time is requested. The third section of the class diagram contains the operations or behaviors of the class. An operation refers to what objects of the class can do. It is usually implemented as a method of the class.

图 A1.1展示了一个对纯种马进行建模的Thoroughbred类的简单示例。它显示了三个属性——母亲、父亲和出生年份。该图还显示了三个操作:getCurrentAge()、 getFather()getMother()。可能还有图中未显示的其他被抑制的属性和操作。

Figure A1.1 presents a simple example of a Thoroughbred class that models thoroughbred horses. It has three attributes displayed— mother, father, and birth year. The diagram also shows three operations: getCurrentAge(), getFather(), and getMother(). There may be other suppressed attributes and operations not shown in the diagram.

图 A1.1 Thoroughbred 类的类图

Figure A1.1 A class diagram for a Thoroughbred class

每个属性都可以有名称、类型和可见性级别。类型和可见性是可选的。类型跟在名称后面,并通过冒号与名称分隔。可见性由前面的 -、#、~ 或 + 表示,分别表示私有、受保护、包公共可见性。在图 A1.1中,所有属性都具有私有可见性,如前导减号 (−) 所示。您还可以通过加下划线来指定属性是静态属性或类属性。每个操作还可以显示可见性级别、带有名称和类型的参数以及返回类型。第613页

Each attribute can have a name, a type, and a level of visibility. The type and visibility are optional. The type follows the name and is separated from the name by a colon. The visibility is indicated by a preceding −, #, ~, or +, indicating, respectively, private, protected, package, or public visibility. In Figure A1.1, all attributes have private visibility, as indicated by the leading minus sign (−). You can also specify that an attribute is a static or class attribute by underlining it. Each operation can also be displayed with a level of visibility, parameters with names and types, and a return type.Page 613

抽象类或抽象方法通过在类图中使用斜体名称来表示。有关示例,请参见图A1.2中的Horse类。接口通过在名称上方添加短语“«interface»”(称为构造型)来表示。请参见图 A1.2中的OwnedObject接口。界面也可以用空心圆以图形方式表示。

An abstract class or abstract method is indicated by the use of italics for the name in the class diagram. See the Horse class in Figure A1.2, for an example. An interface is indicated by adding the phrase “ «interface»” (called a stereotype) above the name. See the OwnedObject interface in Figure A1.2. An interface can also be represented graphically by a hollow circle.

图 A1.2 关于马的类图

Figure A1.2 A class diagram regarding horses

值得一提的是,代表类的图标可以有其他可选部分。例如,类框底部的第四部分可用于列出类的职责。当从 CRC 卡(第 8 章)转换到类图时,本节特别有用,因为在创建执行以下操作的属性和操作之前,可以将 CRC 卡上列出的职责添加到 UML 图中类框中的第四节中。这些责任。本附录中的任何图中均未显示第四部分。

It is worth mentioning that the icon representing a class can have other optional parts. For example, a fourth section at the bottom of the class box can be used to list the responsibilities of the class. This section is particularly useful when transitioning from CRC cards (Chapter 8) to class diagrams in that the responsibilities listed on the CRC cards can be added to this fourth section in the class box in the UML diagram before creating the attributes and operations that carry out these responsibilities. This fourth section is not shown in any of the figures in this appendix.

类图还可以显示类之间的关系。作为另一个类的子类的类通过箭头连接到该类,该箭头的轴为实线,并且带有三角形空心箭头。箭头从子类指向超类。在 UML 中,这种关系称为泛化。例如,在图 A1.2中,ThoroughbredQuarterHorse类被显示为Horse抽象类的子类。箭头轴带有虚线的箭头表示接口的实现。在 UML 中,这种关系称为实现。例如,在图A1.2中,Horse类实现或实现了OwnedObject接口。

Class diagrams can also show relationships between classes. A class that is a subclass of another class is connected to it by an arrow with a solid line for its shaft and with a triangular hollow arrowhead. The arrow points from the subclass to the superclass. In UML, such a relationship is called a generalization. For example, in Figure A1.2, the Thoroughbred and QuarterHorse classes are shown to be subclasses of the Horse abstract class. An arrow with a dashed line for the arrow shaft indicates implementation of an interface. In UML, such a relationship is called a realization. For example, in Figure A1.2, the Horse class implements or realizes the OwnedObject interface.

两个类之间的关联意味着它们之间存在结构关系。关联用实线表示。关联有许多可选部分。它可以被标记,就像它的每个末端一样,以指示每个类在关联中的角色。例如,在图 A1.2中, OwnedObjectPerson之间存在关联,其中Person扮演所有者的角色。关联线一端或两端的箭头指示可导航性。此外,关联线的每一端都可以显示一个多重值。本节稍后将更详细地解释可导航性和多重性。关联还可以使用循环将类与其自身连接起来。这种关联表明该类的一个对象与同一类的其他对象之间的联系。第614页

An association between two classes means that there is a structural relationship between them. Associations are represented by solid lines. An association has many optional parts. It can be labeled, as can each of its ends, to indicate the role of each class in the association. For example, in Figure A1.2, there is an association between OwnedObject and Person in which the Person plays the role of owner. Arrows on either or both ends of an association line indicate navigability. Also, each end of the association line can have a multiplicity value displayed. Navigability and multiplicity are explained in more detail later in this section. An association might also connect a class with itself, using a loop. Such an association indicates the connection of an object of the class with other objects of the same class.Page 614

一端带有箭头的关联表示单向可导航性。箭头表示从一个类您可以轻松访问关联指向的第二个关联类,但从第二个类您不一定能轻松访问第一个类。另一种思考方式是,第一类知道第二类,但第二类不一定直接知道第一类。没有箭头的关联通常表示双向关联,这正是图 A1.2中的意图,但它也可能仅意味着可导航性不重要,因此被忽略。

An association with an arrow at one end indicates one-way navigability. The arrow means that from one class you can easily access the second associated class to which the association points, but from the second class, you cannot necessarily easily access the first class. Another way to think about this is that the first class is aware of the second class, but the second class is not necessarily directly aware of the first class. An association with no arrows usually indicates a two-way association, which is what was intended in Figure A1.2, but it could also just mean that the navigability is not important and so was left off.

应该注意的是,类的属性与类与属性的类类型的关联非常相似。也就是说,为了指示某个类具有 String 类型的名为“name”的属性,可以将该属性显示为属性,如图A1.2中的Horse类所示。或者,可以创建从Horse类到String类的单向关联,其中String类的角色是“名称”。属性方法更适合原始数据类型,而如果属性的类在设计中起主要作用,则关联方法通常更好,在这种情况下,为该类型提供一个类框很有价值。

It should be noted that an attribute of a class is very much the same thing as an association of the class with the class type of the attribute. That is, to indicate that a class has a property called “name” of type String, one could display that property as an attribute, as in the Horse class in Figure A1.2. Alternatively, one could create a one-way association from the Horse class to the String class with the role of the String class being “name.” The attribute approach is better for primitive data types, whereas the association approach is often better if the property’s class plays a major role in the design, in which case it is valuable to have a class box for that type.

依赖关系表示类之间的另一种连接,并由虚线表示(末尾带有可选箭头和可选标签)。如果对第二类的更改可能需要对第一类进行更改,则一个类依赖于另一个类。从一个类到另一个类的关联自动指示一种依赖关系。如果类之间已经存在关联,则类之间不需要虚线。然而,对于瞬态关系(即,一个类不与另一个类保持任何长期连接,但偶尔使用该类),我们应该从第一个类到第二个类画一条虚线。例如,在图 A1.2中,每当调用其getCurrentAge()方法时, Thoroughbred类都会使用Date类,因此该依赖项被标记为“uses”。

A dependency relationship represents another connection between classes and is indicated by a dashed line (with optional arrows at the ends and with optional labels). One class depends on another if changes to the second class might require changes to the first class. An association from one class to another automatically indicates a dependency. No dashed line is needed between classes if there is already an association between them. However, for a transient relationship (i.e., a class that does not maintain any long-term connection to another class but does use that class occasionally) we should draw a dashed line from the first class to the second. For example, in Figure A1.2, the Thoroughbred class uses the Date class whenever its getCurrentAge() method is invoked, and so the dependency is labeled “uses.”

关联一端的多重意味着该类与另一类关联的对象的数量。重数由非负整数或整数范围指定。由“0..1”指定的多重性意味着关联的那一端有 0 或 1 个对象。例如,世界上的每个人要么有社会安全号码,要么没有这样的号码(特别是如果他们不是美国公民),因此可以在 Person 类和 SocialSecurityNumber 之间的关联中使用 0..1类图中的类。由“1..*”指定的重数表示1个以上,由“0..*”或仅“*”指定的重数表示0个以上。在图 A1.2中,* 被用作与类Person关联的OwnedObject端的多重性,因为一个Person可以拥有零个或多个对象。

The multiplicity of one end of an association means the number of objects of that class associated with the other class. A multiplicity is specified by a nonnegative integer or by a range of integers. A multiplicity specified by “0..1” means that there are 0 or 1 objects on that end of the association. For example, each person in the world has either a Social Security number or no such number (especially if they are not U.S. citizens), and so a multiplicity of 0..1 could be used in an association between a Person class and a SocialSecurityNumber class in a class diagram. A multiplicity specified by “1..*” means one or more, and a multiplicity specified by “0..*” or just “*” means zero or more. An * was used as the multiplicity on the OwnedObject end of the association with class Person in Figure A1.2 because a Person can own zero or more objects.

如果关联一端的重数大于 1,则关联一端引用的类的对象可能存储在集合中,例如集合或有序列表。还可以在 UML 图中包含该集合类本身,但这样的类通常会被省略,并且由于关联的多重性而被隐式假定存在。

If one end of an association has multiplicity greater than 1, then the objects of the class referred to at that end of the association are probably stored in a collection, such as a set or ordered list. One could also include that collection class itself in the UML diagram, but such a class is usually left out and is implicitly assumed to be there due to the multiplicity of the association.

聚合是一种特殊的关联由图标一端的空心菱形表示。它表示“整体/部分”关系,因为箭头指向的类被视为关联菱形端的类的“部分”。组合是表明各部分的强大所有权的聚合。在组合中,部件的存在和死亡与所有者有关,因为它们在软件系统中不具有独立于所有者的作用。有关聚合和组合的示例,请参见图 A1.3 。第615页

An aggregation is a special kind of association indicated by a hollow diamond on one end of the icon. It indicates a “whole/part” relationship, in that the class to which the arrow points is considered a “part” of the class at the diamond end of the association. A composition is an aggregation indicating strong ownership of the parts. In a composition, the parts live and die with the owner because they have no role in the software system independent of the owner. See Figure A1.3 for examples of aggregation and composition.Page 615

图A1.3 学院、课程、建筑之间的关系

Figure A1.3 The relationship between Colleges, Courses, and Buildings

学院拥有建筑对象的集合,它们代表构成校园的建筑物。学院还设有一系列课程。如果学院要折叠,建筑物仍然会存在(假设学院没有被物理破坏)并且可以用于其他用途,但是课程对象在提供它的学院之外没有任何用处。如果学院不再作为商业实体存在,则课程对象将不再有用,因此它也将不复存在。

A College has an aggregation of Building objects, which represent the buildings making up the campus. The college also has a collection of courses. If the college were to fold, the buildings would still exist (assuming the college wasn’t physically destroyed) and could be used for other things, but a Course object has no use outside of the college at which it is being offered. If the college were to cease to exist as a business entity, the Course object would no longer be useful and so it would also cease to exist.

类图的另一个常见元素是注释,它由一个带有折角的框表示,并通过虚线连接到其他图标。它可以有任意内容(文本和图形),并且与编程语言注释类似。它可能包含有关类的角色或该类的所有对象必须满足的约束的信息。如果内容是约束,则用大括号将内容括起来。请注意图 A1.3中附加到Course类的约束。

Another common element of a class diagram is a note, which is represented by a box with a dog-eared corner and is connected to other icons by a dashed line. It can have arbitrary content (text and graphics) and is similar in a programming language comment. It might contain information about the role of a class or constraints that all objects of that class must satisfy. If the contents are a constraint, braces surround the contents. Note the constraint attached to the Course class in Figure A1.3.

部署_ _

Deployment Diagrams

UML部署图重点关注软件系统的结构,有助于显示软件系统在硬件平台和执行环境之间的物理分布。例如,假设您正在开发一个基于 Web 的图形渲染包。您的包的用户将使用他们的 Web 浏览器访问您的网站并输入渲染信息。您的网站将根据用户的规范呈现图形图像并将其发送回用户。由于图形渲染的计算成本可能很高,因此您决定将渲染本身从 Web 服务器移至单独的平台上。因此,您的系统中将涉及三个硬件设备:Web 客户端(运行浏览器的用户计算机)、托管 Web 服务器的计算机以及托管渲染引擎的计算机。

A UML deployment diagram focuses on the structure of the software system and is useful for showing the physical distribution of a software system among hardware platforms and execution environments. Suppose, for example, you are developing a Web-based graphics-rendering package. Users of your package will use their Web browser to go to your website and enter rendering information. Your website would render a graphical image according to the user’s specification and send it back to the user. Because graphics rendering can be computationally expensive, you decide to move the rendering itself off the Web server and onto a separate platform. Therefore, there will be three hardware devices involved in your system: the Web client (the users’ computer running a browser), the computer hosting the Web server, and the computer hosting the rendering engine.

图 A1.4显示了此类包的部署图。在这样的图中,硬件组件绘制在标有“设备”的框中。硬件组件之间的通信路径用带有可选标签的线绘制。在图 A1.4中,路径标有通信协议和用于连接设备的网络类型。

Figure A1.4 shows the deployment diagram for such a package. In such a diagram, hardware components are drawn in boxes labeled with “«device»”. Communication paths between hardware components are drawn with lines with optional labels. In Figure A1.4, the paths are labeled with the communication protocol and the type of network used to connect the devices.

图A1.4 部署图

Figure A1.4 A deployment diagram

第616页部署图中的每个节点还可以用有关设备的详细信息进行注释。例如,在图 A1.4中,浏览器客户端被描绘为显示它包含由 Web 浏览器软件组成的工件。工件通常是包含在设备上运行的软件的文件。您还可以指定标记值,如图A1.4中的 Web 服务器节点所示。这些值定义 Web 服务器的供应商和服务器使用的操作系统。

Page 616Each node in a deployment diagram can also be annotated with details about the device. For example, in Figure A1.4, the browser client is depicted to show that it contains an artifact consisting of the Web browser software. An artifact is typically a file containing software running on a device. You can also specify tagged values, as is shown in Figure A1.4 in the Web server node. These values define the vendor of the Web server and the operating system used by the server.

部署图还可以显示执行环境节点,这些节点被绘制为包含标签“执行环境”的框。这些节点代表可以托管其他软件程序的系统,例如操作系统。

Deployment diagrams can also display execution environment nodes, which are drawn as boxes containing the label “«execution environment»”. These nodes represent systems, such as operating systems, that can host other software programs.

用例_ _ _

Use-Case Diagrams

用例(第 7 章和第 8章)和 UML用例图可帮助您从用户的角度确定软件的功能和特性。为了让您了解用例和用例图的工作原理,我们将为管理在线数字音乐商店的软件应用程序创建一些用例和用例图。该软件可能执行的一些操作包括:

Use cases (Chapters 7 and 8) and the UML use-case diagram help you determine the functionality and features of the software from the user’s perspective. To give you a feeling for how use cases and use-case diagrams work, we’ll create some for a software application for managing an online digital music store. Some of the things the software might do include:

  • 下载 MP3 音乐文件并将其存储在应用程序的库中。

  • Download an MP3 music file and store it in the application’s library.

  • 捕获流媒体音乐并将其存储在应用程序的库中。

  • Capture streaming music and store it in the application’s library.

  • 管理应用程序的库(例如,删除歌曲或将它们组织到播放列表中)。

  • Manage the application’s library (e.g., delete songs or organize them in playlists).

  • 将库中的歌曲列表刻录到 CD 上。

  • Burn a list of the songs in the library onto a CD.

  • 将库中的歌曲列表加载到 iPod 或 MP3 播放器上。

  • Load a list of the songs in the library onto an iPod or MP3 player.

  • 将歌曲从 MP3 格式转换为 AAC 格式,反之亦然。

  • Convert a song from MP3 format to AAC format and vice versa.

这不是详尽的列表,但足以理解用例和用例图的作用。

This is not an exhaustive list, but it is sufficient to understand the role of use cases and use-case diagrams.

描述用户如何通过定义实现特定目标(例如,将歌曲列表刻录到 CD 上)所需的步骤来与系统交互。步骤顺序的变化描述了各种场景(例如,如果列表中的所有歌曲都装不下一张 CD 怎么办?)。第617页

A use case describes how a user interacts with the system by defining the steps required to accomplish a specific goal (e.g., burning a list of songs onto a CD). Variations in the sequence of steps describe various scenarios (e.g., what if all the songs in the list don’t fit on one CD?).Page 617

UML 用例图是所有用例及其相互关系的概述。它提供了系统功能的总体情况。数字音乐应用程序的用例图如图A1.5所示。

A UML use-case diagram is an overview of all the use cases and how they are related. It provides a big picture of the functionality of the system. A use-case diagram for the digital music application is shown in Figure A1.5.

图 A1.5 音乐系统的用例图

Figure A1.5 A use-case diagram for the music system

在此图中,简笔画代表与一类用户(或其他交互元素)相关联的参与者第 8 章)。复杂系统通常有多个参与者。例如,自动售货机应用程序可能具有三个参与者,分别代表客户、维修人员和为机器重新装货的供应商。

In this diagram, the stick figure represents an actor (Chapter 8) that is associated with one category of user (or other interaction element). Complex systems typically have more than one actor. For example, a vending machine application might have three actors representing customers, repair personnel, and vendors who refill the machine.

在用例图中,用例显示为椭圆形。参与者通过线路连接到他们执行的用例。请注意,用例的所有详细信息均未包含在图中,而是需要单独存储。另请注意,用例放置在矩形中,但参与者不是。这个矩形是对系统边界和参与者在系统之外的视觉提醒。

In the use-case diagram, the use cases are displayed as ovals. The actors are connected by lines to the use cases that they carry out. Note that none of the details of the use cases are included in the diagram and instead need to be stored separately. Note also that the use cases are placed in a rectangle but the actors are not. This rectangle is a visual reminder of the system boundaries and that the actors are outside the system.

系统中的某些用例可能彼此相关。例如,将歌曲列表刻录到 CD 以及将歌曲列表加载到 iPod 或智能手机都有类似的步骤。在这两种情况下,用户首先创建一个空列表,然后将歌曲从库添加到列表中。为了避免用例重复,通常最好创建一个代表重复活动的新用例,然后让其他用例包含这个新用例作为其步骤之一。这种包含在用例图中表示出来,如图A1.6所示,通过标记为“包含”的虚线箭头将用例与包含的用例连接起来。第618页

Some use cases in a system might be related to each other. For example, there are similar steps in burning a list of songs to a CD and in loading a list of songs to an iPod or smartphone. In both cases, the user first creates an empty list and then adds songs from the library to the list. To avoid duplication in use cases, it is usually better to create a new use case representing the duplicated activity and then let the other use cases include this new use case as one of their steps. Such inclusion is indicated in use-case diagrams, as in Figure A1.6, by means of a dashed arrow labeled «include» connecting a use case with an included use case.Page 618

图 A1.6 包含用例的用例图

Figure A1.6 A use-case diagram with included use cases

用例图显示了所有用例,因此有助于确保您已涵盖系统的所有功能。在我们的数字音乐管理器中,我们肯定需要更多用例,例如在图书馆中播放歌曲的用例。但请记住,用例对软件开发过程最有价值的贡献是每个用例的文本描述,而不是整体用例图 [Fow04]。通过这些描述,您可以清楚地了解您正在开发的系统的目标。

A use-case diagram, because it displays all use cases, is a helpful aid for ensuring that you have covered all the functionality of the system. In our digital music organizer, we would surely want more use cases, such as a use case for playing a song in the library. But keep in mind that the most valuable contribution of use cases to the software development process is the textual description of each use case, not the overall use-case diagram [Fow04]. It is through the descriptions that you are able to form a clear understanding of the goals of the system you are developing.

顺序图_ _

Sequence Diagrams

与显示软件组件的静态结构的类图和部署图不同,序列用于显示任务执行期间对象之间的动态通信。它显示了在对象之间发送消息以完成该任务的时间顺序。人们可以使用序列图来显示软件系统的一种用例或一种场景中的交互。第619页

In contrast to class diagrams and deployment diagrams, which show the static structure of a software component, a sequence diagram is used to show the dynamic communications between objects during execution of a task. It shows the temporal order in which messages are sent between the objects to accomplish that task. One might use a sequence diagram to show the interactions in one use case or in one scenario of the software system.Page 619

图 A1.7中,您可以看到绘图程序的序列图。该图显示了单击图形中的图形时突出显示该图形所涉及的步骤。图表顶部行中的每个框通常对应于一个对象,尽管框可以对其他事物(例如类)进行建模。如果该框代表一个对象(就像我们所有示例中的情况一样),那么在框内您可以选择在冒号前面声明该对象的类型。您还可以在冒号之前键入对象的名称,如图A1.7中的第三个框所示。每个框下面有一条虚线,称为对象的生命线。序列图中的纵轴对应于时间,向下移动时间会增加。

In Figure A1.7, you see a sequence diagram for a drawing program. The diagram shows the steps involved in highlighting a figure in the drawing when it has been clicked. Each box in the row at the top of the diagram usually corresponds to an object, although it is possible to have the boxes model other things, such as classes. If the box represents an object (as is the case in all our examples), then inside the box you can optionally state the type of the object preceded by the colon. You can also precede the colon and type by a name for the object, as shown in the third box in Figure A1.7. Below each box there is a dashed line called the lifeline of the object. The vertical axis in the sequence diagram corresponds to time, with time increasing as you move downward.

图 A1.7 序列图示例

Figure A1.7 A sample sequence diagram

序列图使用从调用者到被调用者的水平箭头显示方法调用,用方法名称标记,并可选择包括其参数、参数类型和返回类型。例如,在图 A1.7中,MouseListener调用DrawinggetFigureAt()方法。当对象正在执行方法时(即,当它在堆栈上有激活帧时),您可以选择在对象的生命线下方显示一个白色条,称为激活条。图 A1.7中,为所有方法调用绘制了激活条。该图还可以选择使用虚线箭头和可选标签显示方法调用的返回。在图 A1.7中,显示了getFigureAt()方法调用的返回,并标有返回的对象的名称。正如我们在图 A1.7中所做的那样,一种常见的做法是在调用 void 方法时省略返回箭头,因为它会使图表变得混乱,同时提供的重要信息很少。带有箭头的黑色圆圈表示找到的消息来源未知或不相关。

A sequence diagram shows method calls using horizontal arrows from the caller to the callee, labeled with the method name and optionally including its parameters, their types, and the return type. For example, in Figure A1.7, the MouseListener calls the Drawing’s getFigureAt() method. When an object is executing a method (that is, when it has an activation frame on the stack), you can optionally display a white bar, called an activation bar, down the object’s lifeline. In Figure A1.7, activation bars are drawn for all method calls. The diagram can also optionally show the return from a method call with a dashed arrow and an optional label. In Figure A1.7, the getFigureAt() method call’s return is shown labeled with the name of the object that was returned. A common practice, as we have done in Figure A1.7, is to leave off the return arrow when a void method has been called, since it clutters up the diagram while providing little information of importance. A black circle with an arrow coming from it indicates a found message whose source is unknown or irrelevant.

您现在应该能够理解图 A1.7显示的任务。未知来源调用MouseListenermouseClicked()方法,并传入单击发生的点作为参数。MouseListener依次调用DrawinggetFigureAt()方法,该方法返回一个Figure。然后,MouseListener调用Figure的highlight 方法,并传入一个Graphics对象作为参数。作为响应,Figure调用Graphics对象的三个方法来绘制红色图形。

You should now be able to understand the task that Figure A1.7 is displaying. An unknown source calls the mouseClicked() method of a MouseListener, passing in the point where the click occurred as the argument. The MouseListener in turn calls the getFigureAt() method of a Drawing, which returns a Figure. The MouseListener then calls the highlight method of Figure, passing in a Graphics object as an argument. In response, Figure calls three methods of the Graphics object to draw the figure in red.

第620页图 A1.7中的图表非常简单,不包含条件或循环。如果需要逻辑控制结构,最好为每种情况绘制单独的序列图。也就是说,如果消息流根据条件可以采取两条不同的路径,则绘制两个单独的序列图,每个序列图对应一种可能性。

Page 620The diagram in Figure A1.7 is very straightforward and contains no conditionals or loops. If logical control structures are required, it is probably best to draw a separate sequence diagram for each case. That is, if the message flow can take two different paths depending on a condition, then draw two separate sequence diagrams, one for each possibility.

如果您坚持在序列图中包含循环、条件和其他控制结构,则可以使用交互框架,它们是围绕图的某些部分的矩形,并标有它们所代表的控制结构的类型。图 A1.8说明了这一点,显示了突出显示给定矩形内的所有图形所涉及的过程。MouseListener被发送 rectDragged 消息然后, MouseListener告诉绘图通过调用方法highlightFiguresIn()并将矩形作为参数传递来突出显示矩形中的所有图形。该方法循环遍历Drawing对象中的所有Figure对象,如果Figure与矩形相交,则要求Figure突出显示自身。方括号中的短语称为“guards”,它们是布尔条件,如果交互框架内的操作要继续,则该条件必须为 true。

If you insist on including loops, conditionals, and other control structures in a sequence diagram, you can use interaction frames, which are rectangles that surround parts of the diagram and that are labeled with the type of control structures they represent. Figure A1.8 illustrates this, showing the process involved in highlighting all figures inside a given rectangle. The MouseListener is sent the rectDragged message. The MouseListener then tells the drawing to highlight all figures in the rectangle by calling the method highlightFiguresIn(), passing the rectangle as the argument. The method loops through all Figure objects in the Drawing object and, if the Figure intersects the rectangle, the Figure is asked to highlight itself. The phrases in square brackets are called guards, which are Boolean conditions that must be true if the action inside the interaction frame is to continue.

图 A1.8 具有两个交互框架的序列图

Figure A1.8 A sequence diagram with two interaction frames

序列图中还可以包含许多其他特殊功能。例如:

There are many other special features that can be included in a sequence diagram. For example:

  1. 您可以区分同步消息和异步消息。同步消息用实线箭头显示,而异步消息用棒箭头显示。

  2. You can distinguish between synchronous and asynchronous messages. Synchronous messages are shown with solid arrowheads, while asynchronous messages are shown with stick arrowheads.

  3. 您可以显示一个对象向自己发送一条消息,其中有一个箭头从该对象伸出,向下转动,然后指向同一对象。

  4. You can show an object sending itself a message with an arrow going out from the object, turning downward, and then pointing back to the same object.

  5. 您可以通过在对象框上绘制适当标记的箭头(例如,带有“创建”标签)来显示对象创建。在这种情况下,该框在图中的显示位置将低于与动作开始时已存在的对象对应的框。第621页

  6. You can show object creation by drawing an arrow appropriately labeled (for example, with a «create» label) to an object’s box. In this case, the box will appear lower in the diagram than the boxes corresponding to objects already in existence when the action begins.Page 621

  7. 您可以在对象生命线末端用一个大 X 来显示对象破坏。其他对象可以销毁一个对象,在这种情况下,箭头从另一个对象指向 X。X 也可用于指示对象不再可用,因此已准备好进行垃圾回收。

  8. You can show object destruction by a big X at the end of the object’s lifeline. Other objects can destroy an object, in which case an arrow points from the other object to the X. An X is also useful for indicating that an object is no longer usable and so is ready for garbage collection.

最后三个功能均显示在图 A1.9的序列图中。

The last three features are all shown in the sequence diagram in Figure A1.9.

图 A1.9 序列图中的创建、销毁和循环

Figure A1.9 Creation, destruction, and loops

in sequence diagrams

通讯_ _

Communication Diagrams

UML通信图(在 UML 1.X 中称为“协作图”)提供了通信时间顺序的另一种指示,但强调对象和类之间的关系而不是时间顺序。图 A1.10显示了一个通信图,它显示了与图 A1.7中的序列图所示相同的操作。

The UML communication diagram (known as a “collaboration diagram” in UML 1.X) provides another indication of the temporal order of the communications, but emphasizes the relationships among the objects and classes instead of the temporal order. A communication diagram is illustrated in Figure A1.10, which displays the same actions shown in the sequence diagram in Figure A1.7.

图 A1.10 UML 通信图

Figure A1.10 A UML communication diagram

在通信图中,交互对象由矩形表示。对象之间的关联由连接矩形的线表示。图中通常有一个指向一个对象的传入箭头,该箭头启动消息传递的序列。该箭头标有数字和消息名称。如果传入消息标有数字 1,并且如果它导致接收对象调用其他对象上的其他消息,则这些消息将由沿着关联线从发送者到接收者的箭头表示,并给出数字 1.1、1.2,等等,按照它们被调用的顺序。如果这些消息又调用其他消息,则会将另一个小数点和数字添加到标记这些消息的数字中,以指示消息传递的进一步嵌套。

In a communication diagram the interacting objects are represented by rectangles. Associations between objects are represented by lines connecting the rectangles. There is typically an incoming arrow to one object in the diagram that starts the sequence of message passing. That arrow is labeled with a number and a message name. If the incoming message is labeled with the number 1 and if it causes the receiving object to invoke other messages on other objects, then those messages are represented by arrows from the sender to the receiver along an association line and are given numbers 1.1, 1.2, and so forth, in the order they are called. If those messages in turn invoke other messages, another decimal point and number are added to the number labeling these messages, to indicate further nesting of the message passing.

图 A1.10中,您可以看到mouseClicked消息调用了方法getFigureAt(),然后调用了highlight()。highlight ()消息调用其他三个消息:setColor()、drawRect()drawString()。每个标签中的编号显示了每条消息的嵌套以及顺序性质。

In Figure A1.10, you see that the mouseClicked message invokes the methods getFigureAt() and then highlight(). The highlight() message invokes three other messages: setColor(), drawRect(), and drawString(). The numbering in each label shows the nesting as well as the sequential nature of each message.

有许多可选功能可以添加到箭头标签中。例如,您可以在数字前面加上字母。传入的箭头可以标记为 A1:mouseClicked(point)。指示执行线程,A。如果在其他线程中执行其他消息,则它们的标签前面将有不同的字母。例如,如果mouseClicked()方法在线程 A 中执行,但它创建了一个新线程 B 并在该线程中调用highlight() ,则从MouseListenerFigure 的箭头将标记为 1.B2:highlight(graphics)。第622页

There are many optional features that can be added to the arrow labels. For example, you can precede the number with a letter. An incoming arrow could be labeled A1: mouseClicked(point). indicating an execution thread, A. If other messages are executed in other threads, their label would be preceded by a different letter. For example, if the mouseClicked() method is executed in thread A but it creates a new thread B and invokes highlight() in that thread, then the arrow from MouseListener to Figure would be labeled 1.B2: highlight(graphics).Page 622

如果您有兴趣显示对象之间的关系以及对象之间发送的消息,那么通信图可能是比序列图更好的选择。如果您对消息传递的时间顺序更感兴趣,那么序列图可能更好。

If you are interested in showing the relationships among the objects in addition to the messages being sent between them, the communication diagram is probably a better option than the sequence diagram. If you are more interested in the temporal order of the message passing, then a sequence diagram is probably better.

活动图_ _

Activity Diagrams

UML活动图通过系统执行的操作之间的控制流来描述系统或系统一部分的动态行为。它与流程图类似,只是活动图可以显示并发流。

A UML activity diagram depicts the dynamic behavior of a system or part of a system through the flow of control between actions that the system performs. It is similar to a flowchart except that an activity diagram can show concurrent flows.

活动图的主要组成部分是动作节点,用圆角矩形表示,对应于软件系统执行的任务。从一个操作节点到另一操作节点的箭头指示控制流。也就是说,两个动作节点之间的箭头表示第一个动作完成后第二个动作开始。实心黑点形成初始节点,指示活动的起点。黑色圆圈包围的黑点是最终节点,表示活动结束。

The main component of an activity diagram is an action node, represented by a rounded rectangle, which corresponds to a task performed by the software system. Arrows from one action node to another indicate the flow of control. That is, an arrow between two action nodes means that after the first action is complete the second action begins. A solid black dot forms the initial node that indicates the starting point of the activity. A black dot surrounded by a black circle is the final node, indicating the end of the activity.

分叉表示将活动分离为两个或多个并发活动它被绘制为一个水平黑条,有一个箭头指向它,两个或多个箭头从它指向外面。每个传出箭头表示可以与对应于其他传出箭头的流同时执行的控制流。这些并发活动可以在一台计算机上使用不同的线程甚至使用不同的计算机来执行。第623页

A fork represents the separation of activities into two or more concurrent activities. It is drawn as a horizontal black bar with one arrow pointing to it and two or more arrows pointing out from it. Each outgoing arrow represents a flow of control that can be executed concurrently with the flows corresponding to the other outgoing arrows. These concurrent activities can be performed on a computer using different threads or even using different computers.Page 623

图 A1.11显示了涉及烘焙蛋糕的示例活动图。第一步是找到食谱。一旦找到配方,就可以测量和混合干成分和湿成分,并预热烤箱。干成分的混合可以与湿成分的混合和烤箱的预热同时进行。

Figure A1.11 shows a sample activity diagram involving baking a cake. The first step is finding the recipe. Once the recipe has been found, the dry ingredients and wet ingredients can be measured and mixed and the oven can be preheated. The mixing of the dry ingredients can be done in parallel with the mixing of the wet ingredients and the preheating of the oven.

图 A1.11 显示如何烘烤蛋糕的 UML 活动图

Figure A1.11 A UML activity diagram showing how to bake a cake

连接是一种同步并发控制的方法。它由带有两个或多个传入箭头和一个传出箭头的水平黑条表示。在所有由传入箭头表示的流程完成之前,由传出箭头表示的控制流程无法开始执行。在图 A1.11中,我们在将湿成分和干成分混合在一起的操作之前有一个连接。这种连接表明在两种混合物混合之前必须混合所有干成分和所有湿成分。图中的第二个连接表示,在开始烘烤蛋糕之前,所有成分必须混合在一起,并且烤箱必须处于合适的温度。第624页

A join is a way of synchronizing concurrent flows of control. It is represented by a horizontal black bar with two or more incoming arrows and one outgoing arrow. The flow of control represented by the outgoing arrow cannot begin execution until all flows represented by incoming arrows have been completed. In Figure A1.11, we have a join before the action of mixing together the wet and dry ingredients. This join indicates that all dry ingredients must be mixed and all wet ingredients must be mixed before the two mixtures can be combined. The second join in the figure indicates that, before the baking of the cake can begin, all ingredients must be mixed together, and the oven must be at the right temperature.Page 624

决策节点对应于基于条件的控制流中的分支这样的节点显示为带有一个传入箭头和两个或多个传出箭头的白色三角形。每个传出箭头都标有一个防护(方括号内的条件)。控制流遵循守卫为 true 的传出箭头。建议确保条件涵盖所有可能性,以便每次到达决策节点时恰好其中一个为真。图 A1.11显示了蛋糕烘烤后的决策节点。如果蛋糕完成,则将其从烤箱中取出。不然烤的时间会长一些。

A decision node corresponds to a branch in the flow of control based on a condition. Such a node is displayed as a white triangle with an incoming arrow and two or more outgoing arrows. Each outgoing arrow is labeled with a guard (a condition inside square brackets). The flow of control follows the outgoing arrow whose guard is true. It is advisable to make sure that the conditions cover all possibilities so that exactly one of them is true every time a decision node is reached. Figure A1.11 shows a decision node following the baking of the cake. If the cake is done, then it is removed from the oven. Otherwise, it is baked for a while longer.

图 A1.11中的活动图没有告诉您每个操作是谁或做什么的。通常,确切的分工并不重要。但如果您确实想指示如何在参与者之间分配操作,您可以用泳道来装饰活动图,如图A1.12所示。顾名思义,泳道是通过将图表划分为条带或“泳道”而形成的,每个条带或“泳道”对应于一名参与者一条车道上的所有动作均由相应的参与者完成。在图A1.12中,Jennie负责混合干配料,然后将干湿配料混合在一起,Helen负责加热烤箱并取出蛋糕,Mary负责其他一切。第625页

One of the things the activity diagram in Figure A1.11 does not tell you is who or what does each of the actions. Often, the exact division of labor does not matter. But if you do want to indicate how the actions are divided among the participants, you can decorate the activity diagram with swimlanes, as shown in Figure A1.12. Swimlanes, as the name implies, are formed by dividing the diagram into strips or “lanes,” each of which corresponds to one of the participants. All actions in one lane are done by the corresponding participant. In Figure A1.12, Jennie is responsible for mixing the dry ingredients and then mixing the dry and wet ingredients together, Helen is responsible for heating the oven and taking the cake out, and Mary is responsible for everything else.Page 625

图A1.12 添加泳道的蛋糕烘焙活动图

Figure A1.12 The cake-baking activity diagram with swimlanes added

状态_ _

State Diagrams

对象在特定时间点的行为通常取决于该对象的状态,即该对象当时的变量值。作为一个简单的例子,考虑一个带有布尔实例变量的对象。当要求执行操作时,如果该变量为true,则该对象可能会执行一件事;如果该变量为 false,则该对象可能会执行其他操作

The behavior of an object at a particular point in time often depends on the state of the object, that is, the values of its variables at that time. As a trivial example, consider an object with a Boolean instance variable. When asked to perform an operation, the object might do one thing if that variable is true and do something else if it is false.

UML状态图对对象的状态、根据这些状态执行的操作以及对象状态之间的转换进行建模。

A UML state diagram models an object’s states, the actions that are performed depending on those states, and the transitions between the states of the object.

作为示例,请考虑 Java 编译器的一部分的状态图。编译器的输入是一个文本文件,可以将其视为一长串字符。编译器一次读取一个字符,并从中确定程序的结构。读取字符的过程的一小部分涉及忽略“空白”字符(例如,空格、制表符、换行符回车符)和注释内的字符。

As an example, consider the state diagram for a part of a Java compiler. The input to the compiler is a text file, which can be thought of as a long string of characters. The compiler reads characters one at a time and from them determines the structure of the program. One small part of this process of reading the characters involves ignoring “white-space” characters (e.g., the space, tab, newline, and return characters) and characters inside a comment.

假设编译器将处理空白字符和注释中的字符的工作委托给WhiteSpaceAndCommentEliminator 。也就是说,该对象的工作是读取输入字符,直到读取所有空白和注释字符,此时它将控制权返回给编译器以读取和处理非空白和非注释字符。考虑一下WhiteSpaceAndCommentEliminator对象如何读取字符并确定下一个字符是空格还是注释的一部分。该对象可以通过针对“ ”、“\t”、“\n”和“\r”测试下一个字符来检查空格。但它如何确定下一个字符是否是评论的一部分呢?例如,当它第一次看到“/”时,它还不知道该字符是否表示除法运算符、/= 运算符的一部分,或者行或块注释的开头。为了做出这个决定,WhiteSpaceAndCommentEliminator需要记下它看到“/”的事实,然后继续处理下一个字符。如果“/”后面的字符是另一个“/”或“*”,则WhiteSpaceAndCommentEliminator知道它现在正在读取注释,并且可以前进到注释的末尾,而不处理或保存任何字符。如果第一个“/”后面的字符不是“/”或“*”,则WhiteSpaceAndCommentEliminator知道“/”代表除法运算符或 /= 运算符的一部分,因此它会停止在字符上前进。

Suppose that the compiler delegates to a WhiteSpaceAndCommentEliminator the job of advancing over white-space characters and characters in comments. That is, this object’s job is to read input characters until all white-space and comment characters have been read, at which point it returns control to the compiler to read and process non-white-space and noncomment characters. Think about how the WhiteSpaceAndCommentEliminator object reads in characters and determines whether the next character is white space or part of a comment. The object can check for white space by testing the next character against “ ”, “\t”, “\n”, and “\r”. But how does it determine whether the next character is part of a comment? For example, when it sees a “/” for the first time, it doesn’t yet know whether that character represents a division operator, part of the /= operator, or the beginning of a line or block comment. To make this determination, WhiteSpaceAndCommentEliminator needs to make a note of the fact that it saw a “/” and then move on to the next character. If the character following the “/” is another “/” or an “*”, then WhiteSpaceAndCommentEliminator knows that it is now reading a comment and can advance to the end of the comment without processing or saving any characters. If the character following the first “/” is anything other than a “/” or an “*”, then WhiteSpaceAndCommentEliminator knows that the “/” represents the division operator or part of the /= operator and so it stops advancing over characters.

总而言之,当WhiteSpaceAndCommentEliminator读取字符时,它需要跟踪几件事,包括当前字符是否为空格、读取的前一个字符是否是“/”、当前是否正在读取注释中的字符、是否已到达评论末尾,依此类推。这些都对应于WhiteSpaceAndCommentEliminator对象的不同状态。在每种状态下,WhiteSpaceAndCommentEliminator对于读入的下一个字符的行为都不同。

In summary, as WhiteSpaceAndCommentEliminator reads in characters, it needs to keep track of several things, including whether the current character is white space, whether the previous character it read was a “/”, whether it is currently reading characters in a comment, whether it has reached the end of comment, and so forth. These all correspond to different states of the WhiteSpaceAndCommentEliminator object. In each of these states, WhiteSpaceAndCommentEliminator behaves differently with regard to the next character read in.

为了帮助您可视化该对象的所有状态以及它如何更改状态,您可以使用 UML 状态图,如图A1.13所示。状态图使用圆角矩形显示状态,每个状态的上半部分都有一个名称。还有一个黑色圆圈称为“初始伪状态”,它并不是真正的状态,而只是指向初始状态。图A1.13中,起始状态为初始状态。从一种状态到另一种状态的箭头表示对象状态的转变或变化。每个转换都标有触发事件、斜线 (/) 和活动。状态图中转移标签的所有部分都是可选的。如果对象处于一种状态并且发生其转换之一的触发事件,则执行该转换的活动并且对象呈现由转换指示的新状态。例如,在图 A1.13中,如果WhiteSpaceAndCommentEliminator对象处于开始状态并且下一个字符是“/”,则WhiteSpaceAndCommentEliminator会前进到该字符并更改为看到的“/”状态。如果“/”后面的字符是另一个“/”,则对象前进到行注释状态并停留在那里,直到读取到行尾字符。相反,如果“/'”之后的下一个字符是“*”,则对象前进到块注释状态并停留在那里,直到看到另一个“*”后跟“/”,这表示块的结束评论。研究该图以确保您理解它。请注意,在前进到空白或注释之后,WhiteSpaceAndCommentEliminator将返回到开始状态并重新开始。这种行为是必要的,因为 Java 源代码中的任何其他字符之前可能有多个连续的注释或空白字符。第626页

To help you visualize all the states of this object and how it changes state, you can use a UML state diagram as shown in Figure A1.13. A state diagram displays states using rounded rectangles, each of which has a name in its upper half. There is also a black circle called the “initial pseudostate,” which isn’t really a state and instead just points to the initial state. In Figure A1.13, the start state is the initial state. Arrows from one state to another state indicate transitions or changes in the state of the object. Each transition is labeled with a trigger event, a slash (/), and an activity. All parts of the transition labels are optional in state diagrams. If the object is in one state and the trigger event for one of its transitions occurs, then that transition’s activity is performed and the object takes on the new state indicated by the transition. For example, in Figure A1.13, if the WhiteSpaceAndCommentEliminator object is in the start state and the next character is “/”, then WhiteSpaceAndCommentEliminator advances past that character and changes to the saw ‘/’ state. If the character after the “/” is another “/”, then the object advances to the line comment state and stays there until it reads an end-of-line character. If instead the next character after the “/’”is a “*”, then the object advances to the block comment state and stays there until it sees another “*” followed by a “/”, which indicates the end of the block comment. Study the diagram to make sure you understand it. Note that, after advancing past white space or a comment, WhiteSpaceAndCommentEliminator goes back to the start state and starts over. That behavior is necessary since there might be several successive comments or white-space characters before any other characters in the Java source code.Page 626

图 A1.13 Java 中推进过去的空白和注释的状态图

Figure A1.13 A state diagram for advancing past white space and comments in Java

对象可以转换到最终状态,由周围有白色圆圈的黑色圆圈表示,这表示不再有转换。在图 A1.13中,当下一个字符不是空格或注释的一部分时, WhiteSpaceAndCommentEliminator对象完成。请注意,除了导致最终状态的两个转换之外,所有转换都具有前进到下一个字符的活动。到最终状态的两次转换不会提前到下一个字符,因为下一个字符是编译器感兴趣的单词或符号的一部分。请注意,如果对象处于锯齿“/”状态,但下一个字符不是“/”或“*”,则“/”是除法运算符或/=运算符的一部分,因此我们不希望推进。其实我们是想备份一个字符,让“/”变成下一个字符,这样“/”才能被编译器使用。在图A1.13中,该备份活动被标记为推回“/”。第627页

An object may transition to a final state, indicated by a black circle with a white circle around it, which indicates there are no more transitions. In Figure A1.13, the WhiteSpaceAndCommentEliminator object is finished when the next character is not white space or part of a comment. Note that all transitions except the two transitions leading to the final state have activities consisting of advancing to the next character. The two transitions to the final state do not advance over the next character because the next character is part of a word or symbol of interest to the compiler. Note that if the object is in the saw ‘/’ state but the next character is not “/” or “*”, then the “/” is a division operator or part of the /= operator and so we don’t want to advance. In fact, we want to back up one character to make the “/” into the next character, so that the “/” can be used by the compiler. In Figure A1.13, this activity of backing up is labeled as pushback ‘/’.Page 627

状态图将帮助您发现错过的或意外的情况。也就是说,利用状态图,可以相对容易地确保所有可能状态的所有可能触发事件都已被考虑在内。例如,在图 A1.13中,您可以轻松验证每个状态是否都包含所有可能字符的转换。

A state diagram will help you to uncover missed or unexpected situations. That is, with a state diagram, it is relatively easy to ensure that all possible trigger events for all possible states have been accounted for. For example, in Figure A1.13, you can easily verify that every state has included transitions for all possible characters.

UML 状态图可以包含图 A1.13中未包含的许多其他功能。例如,当一个对象处于某种状态时,它通常除了等待触发事件发生之外什么也不做。然而,有一种特殊的状态,称为活动状态,其中对象在处于该状态时执行一些活动,称为do-activity 。为了表明状态是状态图中的活动状态,您可以在状态圆角矩形的下半部分中包含短语“do/”,后跟处于该状态时要完成的活动。do-activity 可能会在任何状态转换发生之前完成,之后活动状态的行为就像正常的等待状态一样。如果在 do-activity 完成之前发生从 Activity 状态的转换,则 do-activity 会被中断。

UML state diagrams can contain many other features not included in Figure A1.13. For example, when an object is in a state, it usually does nothing but sit and wait for a trigger event to occur. However, there is a special kind of state, called an activity state, in which the object performs some activity, called a do-activity, while it is in that state. To indicate that a state is an activity state in the state diagram, you include in the bottom half of the state’s rounded rectangle the phrase “do/” followed by the activity that is to be done while in that state. The do-activity may finish before any state transitions occur, after which the activity state behaves like a normal waiting state. If a transition out of the activity state occurs before the do-activity is finished, then the do-activity is interrupted.

由于转换发生时触发事件是可选的,因此可能不会将任何触发事件列为转换标签的一部分。在这种情况下,对于正常等待状态,对象将立即从该状态转换到新状态。对于活动状态,一旦 do-activity 完成,就会进行这种转换。

Because a trigger event is optional when a transition occurs, it is possible that no trigger event may be listed as part of a transition’s label. In such cases for normal waiting states, the object will immediately transition from that state to the new state. For activity states, such a transition is taken as soon as the do-activity finishes.

第628页图 A1.14使用商务电话的状态说明了这种情况。当呼叫者被置于保持状态时,呼叫将进入“音乐保持”状态(播放舒缓的音乐 10 秒)。10 秒后,该状态的 do-activity 完成,并且该状态的行为类似于正常的非活动状态。如果呼叫者在呼叫处于“音乐保持”状态时按 # 键,呼叫将转换为“已取消”状态,然后立即转换为拨号音状态。如果在 10 秒舒缓音乐结束之前按下 # 键,则活动将被中断,音乐将立即停止。

Page 628Figure A1.14 illustrates this situation using the states for a business telephone. When a caller is placed on hold, the call goes into the On hold with music state (soothing music is played for 10 seconds). After 10 seconds, the do-activity of the state is completed and the state behaves like a normal nonactivity state. If the caller pushes the # key when the call is in the On hold with music state, the call transitions to the Canceled state and then transitions immediately to the dial tone state. If the # key is pushed before the 10 seconds of soothing music has completed, the do-activity is interrupted and the music stops immediately.

图 A1.14 具有活动状态和无触发转换的状态图

Figure A1.14 A state diagram with an activity state and a triggerless transition

1本附录由 Dale Skrien 贡献,改编自他的书《Java 面向对象设计和设计模式简介》(McGraw-Hill,2008 年)。所有内容均经许可使用。

1 This appendix has been contributed by Dale Skrien and has been adapted from his book, An Introduction to Object-Oriented Design and Design Patterns in Java (McGraw-Hill, 2008). All content is used with permission.

2请参阅 https://www.omg.org/spec/UML/2.5.1/。本文档包含 UML 2.5.1 建模语言的当前规范。

2 See https://www.omg.org/spec/UML/2.5.1/. This document contains the current specification for the UML 2.5.1 modeling language.

第629页

Page 629

附录

Appendix

2软件工程师的数据科学

2 Data Science for Software Engineers

贡献者:William Grosky 和 ​​Terry Ruas 1

Contributed by: William Grosky and Terry Ruas1

数据科学——大局_ _ _ _ _ _

DATA SCIENCE—THE BIG PICTURE

数据科学融合了许多不同学科的工作,将原始数据转化为信息、知识,并有望转化为智慧。数据科学有着悠久的历史,它融合了计算机科学、数学、统计学、数据可视化的概念以及算法及其实现。详尽详细介绍“数据科学”标题下的所有概念超出了本附录的范围。相反,我们希望提供最重要主题的简洁总结,同时将它们与软件工程联系起来。

Data science incorporates the work of many different disciplines to transform raw data into information, knowledge, and, hopefully, into wisdom. Data science has a long history that incorporates concepts from computer science, mathematics, statistics, data visualization, along with algorithms and their implementations. It is beyond the scope of this appendix to exhaustively detail all concepts under the rubric of “data science.” Instead, we hope to provide a concise summary of the most important topics while connecting them to software engineering.

图A2.1表明数据科学是三个主要领域的交叉点:计算机科学、数学和统计学以及领域知识[Con10]。

Figure A2.1 indicates that data science is the intersection of three major areas: computer science, mathematics and statistics, and domain knowledge [Con10].

图A2.1 数据科学维恩图

Figure A2.1 Data science Venn diagram

数据科学家必须对数据本身感兴趣。数据科学家利用数学和统计学知识以及特定领域的知识,培养必要的技能来评估数据、实验和评估是否针对给定问题进行了适当的设计。然而,要将这些能力带到不同的场景,需要一定的灵活性,而良好的计算能力可以成为实现这一目标的途径。

A data scientist must be interested in more than the data itself. Using knowledge of mathematics and statistics along with domain-specific knowledge, the data scientist develops necessary skills to evaluate whether data, experiments, and evaluation are properly designed for a given problem. However, to bring these capabilities to different scenarios requires a certain flexibility, and good computing skills can be the way to accomplish it.

流行语言、API 和工具

Popular Languages, APIs, and Tools

数据科学的一大优点是您几乎可以在任何允许操作数据的环境中使用它。但要实现这一目标,您需要编程语言、API 和工具来让您的生活更轻松。我们将在以下部分中概述这些内容。

One of the great things about data science is that you can use it in virtually any environment that allows you to manipulate data. But to accomplish this, you’ll need programming languages, APIs, and tools to make your lives easier. We’ll provide an overview of these in the following sections.

语言当谈到编程语言时,我们都会偏向于我们最喜欢的一种。对于数据科学从业者来说,这没有什么不同。但是,您应该记住,一种方法并不适合所有情况,数据科学应用程序语言选择的正确方法是为正确的工作选择正确的工具,考虑其限制、上下文和目标。第630页

Languages When it comes to programming languages, we all have our biases toward the one we like the most. For practitioners in data science, this is no different. However, you should keep in mind that one size does not fit all, and the proper approach to language selection for data science applications is to choose the right tool for the right job, considering its constraints, contexts, and goals.Page 630

对于数据科学应用来说,快速原型设计是一个强烈需要的特性,它使我们能够使用简化且直观的语法来生成有趣的项目。与目的和性能相关的可用资源在编程语言的采用中也发挥着至关重要的作用。因此,一种语言使用得越少,它对我们日常任务的吸引力就越小。数据科学与数据修改密切相关,2是“将数据从一种‘原始’数据形式转换和映射到另一种格式的过程,目的是使其更适合各种下游目的,例如分析。 ”。数据修改是一项耗时的活动,通过记录良好的 API 和库提供的社区支持可以产生重大影响,特别是在寻找使用示例、有关特定方法、约束和其他技术方面的详细信息时。因此,用于数据科学应用的编程语言应该得到广泛采用、支持和记录。

For data science application, fast prototyping is a strongly desired characteristic, one that allows us to produce interesting projects with a simplified and intuitive syntax. The resources available with respect to purpose and performance also play a crucial role in the adoption of a programming language. Thus, the less used a language is, the less attractive it will be for our daily tasks. Data science is closely related with data munging,2 which is “the process of transforming and mapping data from one ‘raw’ data form into another format with the intent of making it more appropriate and valuable for a variety of downstream purposes, such as analytics.” Data munging is a time-consuming activity and community support through well-documented APIs and libraries can make a significant difference, especially when looking for use examples, details about specific methods, constraints, and other technical aspects. Thus, a programming language used for data science applications should be broadly adopted, supported, and documented.

因此,Python 在数据科学社区中广泛使用也就不足为奇了。其他在数据科学家中崛起的有前途的编程语言是 Scala 和 Julia,它们都更关注高性能和可扩展性。R 是数据操作的另一个有趣选择,专门用于统计函数和数据可视化库。由于其架构主要侧重于统计分析、数据清理和数据可视化,因此 R 不应该是通用编程的首选。换句话说,如果使用 R 来解决正确的问题,它会非常有效。

Therefore, it should come as no surprise that Python is widely used in the data science community. Other promising programming languages rising among data scientists are Scala and Julia, both more concerned with high performance and scalability. R is another interesting choice for data manipulation, specialized in statistical functions and data visualization libraries. Because its architecture is focused mainly on statistical analysis, data cleaning, and data visualization, R should not be your first choice for general-purpose programming. In other words, R is highly effective if used to solve the right problems.

Java 在数据科学和软件开发的许多其他领域的流行是无可争议的。紧随最近数据科学和大数据的趋势,Java也有专用的框架,例如Hive、Spark 3、4和Hadoop。5考虑到其非特定架构和冗长,Java 不应该成为高级统计分析或数据处理的首选,尤其是机器学习算法。对于这些情况,Python 和 R 提供了可能更有趣的动态脚本和庞大的专用库。其他强大的编程语言包括 C/C++、F#、SQL,但在数据科学家中并不那么流行。第631页

Java’s popularity is indisputable in data science and many other areas of software development. Following the recent trends in data science and big data, Java also has dedicated frameworks, such as Hive,3 Spark,4 and Hadoop.5 Considering its nonspecific architecture and verbosity, Java should not be the first option for advanced statistical analysis or data munging, especially for machine-learning algorithms. For these cases, Python and R offer dynamic scripting and huge dedicated libraries that might be more interesting. Other strong programming languages, but not that popular among data scientists, are C/C++, F#, SQL.Page 631

库和工具

Libraries and Tools

如果不提及在从数据中提取知识的过程中帮助您的工件,就不可能谈论数据科学。在本节中,我们将介绍 Python [Van16] 中提供的一些最流行的功能。

It is impossible to talk about data science without referring to the artifacts that assist you in the process of extracting knowledge out of data. In this section, we’ll note some of the most popular ones offered in Python [Van16].

NumPy 专为高效操作n维数组和处理科学任务而设计。您可以重塑行数和列数、切片矩阵、执行线性代数运算、排序、搜索以及执行许多其他有用的任务。NumPy 被大量其他库使用,并且它是 SciPy 堆栈的一部分。

NumPy is designed especially to efficiently manipulate n-dimensional arrays and handle scientific tasks. You can reshape the number of rows and columns, slice matrices, perform linear algebra operations, sort, search, and perform many other useful tasks. NumPy is used by a vast number of other libraries, and it is part of the SciPy stack.

SciPy 有两种,库本身和科学堆栈,由多个开源生态系统组成,包括前者。构成科学堆栈的子库有:NumPy、SciPy、Matplotlib、IPython、Sympy 和 Pandas。该库构建在 NumPy 之上,旨在提供有效的方法来处理优化、集成和其他一些有用的操作 [Nun17]、[Sci18]。

There are two kinds of SciPy, the library itself and the scientific stack, composed of several open-source ecosystems, including the former. The sub-libraries that form the scientific stack are: NumPy, SciPy, Matplotlib, IPython, Sympy, and Pandas. The library, which is built on top of NumPy, is designed to provide efficient methods to deal with optimization, integration, and several other useful operations [Nun17], [Sci18].

作为科学生态系统的一部分,Pandas 通过简单的操作帮助您进行数据结构和分析。它允许您直观地塑造数据,提供从非结构化数据到结构化数据框架的轻松适应性。Pandas 中的一些有用功能包括:索引、标记、修复丢失的数据记录以及与不同数据结构的轻松集成 [McK17]、[Num18]。

As part of the scientific ecosystem, Pandas helps you with data structures and analysis through easy manipulations. It allows you to shape your data intuitively, providing easy adaptability from unstructured data to structured DataFrames. Some useful functions in Pandas include: indexing, labeling, fixing missing data records, and easy integration with different data structures [McK17], [Num18].

对于数据科学尤其重要,Python 还拥有大量机器学习库,其中 Scikit-learn、TensorFlow 和 Keras 在聚光灯下占有特殊的地位。Scikit-learn 可能是 Python 中最著名的现成机器学习库之一,具有多种算法类型,例如聚类、回归、分类和降维 [Ger17]。TensorFlow 最初由 Google Brain 团队(Google 人工智能部门的一部分)开发,为每个人提出了一个开源机器学习和深度学习框架。

Particularly important for data science, Python also has a large portfolio of machine-learning libraries, in which Scikit-learn, TensorFlow, and Keras have a special place in the spotlight. Scikit-learn is probably one of the most known off-the-shelf machine-learning libraries in Python, featuring several algorithm types, such as clustering, regression, classification, and dimensionality reduction [Ger17]. TensorFlow, originally developed by the Google Brain team (part of Google’s AI division), proposes an open-source machine-learning and deep-learning framework for everyone.

除了提供的库之外,Python 还有其他几个用于数据科学的专用工具。可视化工具的例子有 Matplotlib、Seaborn、Bokeh 和 Plotly;自然语言处理 (NLP) 工具的示例包括自然语言工具包 (NLTK)、Gensim、spaCy 和 Scrapy [Act18]。

Aside from the presented libraries, Python also has several other specialized tools that are used in data science. Examples of visualization tools are Matplotlib, Seaborn, Bokeh, and Plotly; examples of natural language processing (NLP) tools are Natural Language Toolkit (NLTK), Gensim, spaCy, and Scrapy [Act18].

数据科学机器学习_ _ _

DATA SCIENCE AND MACHINE LEARNING

数据科学是一组数据驱动方法的总称,用于寻找非常困难的问题的近似解决方案。数据科学的主要支持技术是机器学习,这是一套基于统计的技术,它使用归纳方法,试图从一组已知的范例推广到未知的范例。第632页

Data science is an umbrella term for a collection of data-driven approaches for finding approximate solutions to very difficult problems. The main enabling technology of data science is machine learning, a suite of statistics-based techniques that use an inductive approach that attempts to generalize from a set of known exemplars to unknown exemplars.Page 632

例如,我们的环境可以由一组各种气象条件的多个读数组成,例如高温、低温、湿度以及其他几个值。然后,我们得到这些示例的一小部分,即我们已知的范例,并进行标记;也就是说,对于这个小集合中的每个示例,系统都会被告知第二天是否下雨。然后,系统根据已知样本的训练集构建一个数学模型,对未知的日常样本进行分类,以确定第二天是否会下雨。软件工程的另一个例子是根据错误和无错误程序的训练集来预测单个代码是否有错误。或者,我们可能会尝试根据同一程序先前版本的成本历史来预测开发新版本程序的成本。

For example, our environment can consist of a set of multiple readings of various meteorological conditions, such as high temperature, low temperature, humidity, as well as several other values. We then have a small subset of these examples, our known exemplars, that are labeled; that is, for each example in this small set, the system is told whether it rained the following day or not. From this training set of known exemplars, the system then constructs a mathematical model to categorize an unknown daily example as to whether or not it will rain the following day. Another example from software engineering would be to predict whether an individual piece of code has a fault, based on a training set of faulty and nonfaulty programs. Alternatively, we might try to predict the cost of developing a new version of a program, based on the history of costs of previous versions of that same program.

在模型构建中,尝试构建概括训练数据的模型与遵循奥卡姆剃刀普遍持有的原则(即模型应尽可能简单以解释当前训练集数据)之间存在固有的矛盾。 。图 A2.2说明了这个难题。如果训练集仅由圆形组成,奥卡姆剃刀会选择线性模型,但在训练集中添加三角形后,奥卡姆剃刀可能会选择正弦曲线。那么,哪种模型才是合适的:直线、正弦曲线,还是一些目前未知的曲线?

In model building, there is an inherent tension between trying to construct a model that generalizes the training data, along with following the commonly held principle of Occam’s razor, which is that the model should be as simple as possible to explain the current training set data. Figure A2.2 illustrates this conundrum. If the training set consists of only the circles, Occam’s razor would choose the linear model, but with the addition of the triangle into the training set, perhaps Occam’s razor would choose the sine curve. So, which is the appropriate model: straight line, sine curve, or some, as yet, unknown curve?

图 A2.2 线性模型、非线性模型、非线性模型

Figure A2.2 Linear versus nonlinear versus nonlinear model

在气象示例中,系统试图发现气象读数之间的共性,同时发现差异,无论是在第二天下雨的日子还是第二天不下雨的日子的训练集中。然后它使用此元数据来确定明天是否会下雨。类似地,在第一个软件工程示例中,系统尝试在训练集中发现有故障的程序和无故障的程序之间的共性,以及有故障的程序和无故障的程序有何不同,最终能够确定未知程序是否存在是否有故障。在第二个软件工程示例中,系统尝试找到连接训练集中程序的后续版本的成本的一般规则,使用该规则来预测不在训练集中的后续版本的成本。第633页

In the meteorological example, the system tries to discover commonalities and, at the same time, differences among the meteorological readings, both in the training set for the days it rained the following day and for the days it didn’t rain the following day. Then it uses this metadata to determine whether or not it will rain tomorrow. Similarly, in the first software engineering example, the system tries to discover commonalities, in the training set, among programs with faults and those with no faults, as well as how faulty and nonfaulty programs differ, eventually being able to determine whether an unknown program is faulty or not. In the second software engineering example, the system tries to find a general rule that connects the cost of succeeding versions of programs in the training set, using this rule to predict the cost of succeeding versions not in the training set.Page 633

数据分析项目期间遵循的过程包括 (1) 收集适当的数据,(2)清理数据,(3)转换数据,(4)分析数据,然后 (5)制作训练集。

The process which is followed during a data analytics project consists of (1) collecting the appropriate data, (2) cleaning the data, (3) transforming the data, (4) analyzing the data, and then (5) fabricating a training set.

  1. 数据采集​​。考虑收集哪些数据非常重要,因为这取决于您项目的目标。应回答的问题包括需要什么类型的数据以及应收集多少数据。例如,对于软件工程数据收集,需要什么类型的工件?我们需要源代码、目标代码、错误日志吗?我们需要多少数据才能进行适当的分析?

  2. Data collection. Thinking about what data to collect is quite important, as it depends on the goal of your project. Questions that should be answered include what type of data is needed and how much data should be collected. For example, for software engineering data collection, what type of artifacts are needed? Do we need source code, object code, bug logs? What volume of data do we need to do the appropriate analytics?

  3. 数据清理。一旦收集完毕,必须对数据进行清理。此过程包括消除数据中可能导致进一步处理出现问题的问题。例如,应填写缺失的数据,应找到并纠正损坏的数据。

  4. Data cleaning. Once collected, the data must be cleaned. This is a process that consists of eliminating problems in the data that would cause problems in further processing. For example, missing data should be filled in, and corrupt data should be found and corrected.

  5. 数据转换。清理后,应该对数据进行转换,以便它们更适合下游分析任务。这个过程称为数据整理数据整理。此活动的一个示例可能是更改数据显示的格式、消除文本数据文件中的标点符号以及对文本数据进行词性分析。

  6. Data transformation. After cleaning, data should be transformed so they are more suitable for the downstream analytics tasks. This process is called data munging or data wrangling. An example of this activity might be changing the format in which the data appears, eliminating punctuation in a text data file, and doing parts-of-speech analysis for text data.

  7. 数据分析。所有这些之后,数据就可以由各种数据分析工具进行分析和处理。但是,在此之前,我们通常会使用可视化工具来完成各种任务。例如,它可以帮助我们确定使用哪些特征来预测其他特征的值。只有在此之后,我们才能确定用于预测或推理目的的最佳分析方法。

  8. Data analysis. After all this, the data are ready to be analyzed and processed by various data analytics tools. But, before this happens, we generally use visualization tools for various tasks. For example, it may help us determine which features to use to predict the value of other features. It is only after this that we can determine the best analytical approach to be used for predictive or inferential purposes.

  9. 训练集制作。选择合适的训练集很重要。不同训练集产生的概括可能会有所不同,但希望产生的下游答案仍然是正确的。重要的是不要过度拟合训练集,这意味着该方法以接近 100% 的准确度预测训练集中的项目,但在很大程度上无法预测未知项目的正确结果。如果不小心避免这种结果,这种情况很容易发生。所有这些都是通过在测试数据集上测试派生的统计模型以确定其错误率来确定的。

  10. Training set fabrication. Choosing an appropriate training set is important. The generalizations produced from different training sets might differ among themselves, but the hope is that the downstream answers produced are still correct. It is important not to overfit the training set, which means that the approach predicts items in the training set with close to 100 percent accuracy but largely fails to predict the correct results for unknown items. This can happen quite easily if one is not careful to try to avoid this outcome. All of this is determined by testing the derived statistical model on a test set of data to determine its error rate.

为了使上述过程发挥作用,对象必须用某种可以轻松操作并相互比较的数学结构来表示。将数学结构与单个对象关联起来的常见方法是使用特征向量。特征是对象的给定属性特征向量是对象类的多个特征的值的向量,使得同一对象类中的对象的特征向量具有相同的特征排序。例如,一天的气象特征可以具有以下结构:低温、高温、低湿、高湿、盛行云型、总体风力。低温、高温、低湿、高湿变量为连续变量,盛行云型为无序分类变量,总体风强为有序分类变量(假设可能值较弱) ,平均,强)。

For the above process to work, objects must be represented by some mathematical structure that can be manipulated easily and compared among themselves. A common way of associating a mathematical structure with an individual object is to use feature vectors. A feature is a given property of an object. A feature vector is a vector of values for multiple features of an object class, so that the feature vectors for objects in the same object class have the same feature ordering. For example, the meteorological features of a day may have the following structure: low-temperature, high-temperature, low-humidity, high-humidity, prevailing-cloud-type, overall-wind-strength. The variables of low-temperature, high-temperature, low-humidity, high humidity are continuous variables, while prevailing-cloud-type is an unordered categorical variable and overall-wind-strength is an ordered categorical variable (assuming the possible values are weak, average, strong).

第634页在软件工程环境中,一段代码对应的特征向量可以是多个软件度量值的向量,例如代码行数、平均程序执行时间、内聚性和耦合性。选择适当的特征向量通常具有挑战性,而特征工程这一新的研究领域已经发展起来,以帮助指导这一过程。

Page 634In the software engineering environment, a feature vector corresponding to a piece of code could be a vector of values of several software metrics, such as number of lines of code, average program execution time, cohesion, and coupling. It is often challenging to choose the appropriate feature vector, and a new area of study, feature engineering, has evolved to help guide the process.

机器学习方法

Machine-Learning Approaches

机器学习是数据科学不可或缺的一部分。本节前面讨论的过程建立了用于驱动学习的数据集。监督学习由用户参与循环并与学习系统交互的方法组成,主要通过提供某些类型的元信息,例如训练集的标记数据。无监督学习不让用户参与提供分类信息的循环。这些技术纯粹是数据驱动的,并找到从数据本身标记数据的方法。

Machine learning is an integral part of data science. The process discussed earlier in this section establishes the data set that is used to drive learning. Supervised learning consists of approaches where the user is in the loop and interacts with the learning system, mainly by providing certain types of meta-information, such as labeled data for training sets. Unsupervised learning does not have the user in the loop to provide categorical information. These techniques are purely data driven and find ways of labeling the data from the data itself.

在监督学习方法中,有两种主要类型的问题:分类问题和回归问题。

Within supervised learning approaches, there are two main types of problems: classification problems and regression problems.

分类问题的目的是确定一个实体属于几个类别中的哪一个;换句话说,预测类标签。具有两个可能标签的问题称为二元分类问题,而具有两个以上类别的问题称为多类分类问题。如果一个实体可以分为多个类别,我们就遇到了多标签分类问题。在这种情况下,经常会发生单个类中实体的成员资格与 0 到 1 之间的数字相关联的情况。该数字可以解释为成员资格的强度或成员资格的概率。在这种情况下,对于给定实体,其所有关联成员资格强度或概率的总和等于 1。二元分类问题的一个典型示例是将电子邮件分类为垃圾邮件或非垃圾邮件。多类分类问题的一个示例是将电子邮件的内容分类到不同的主题类。

Classification problems are those whose aim is to determine which of several classes an entity belongs; in other words, to predict a class label. A problem with two possible labels is called a binary classification problem, while a problem with more than two classes is called a multiclass classification problem. If an entity can fall into several classes, we have a multilabel classification problem. In this case, it often happens that the membership of an entity in an individual class is associated with a number between 0 and 1. This number can be interpreted as the strength of membership or the probability of membership. In this case, for a given entity, the sum of all its associated membership strengths or probabilities is equal to 1. A classic example of a binary classification problem is to classify e-mail as spam or nonspam. An example of a multiclass classification problem would be to classify the contents of an e-mail to various topic classes.

回归问题的目的是在给定多个输入变量的值的情况下预测输出变量的值。预测值可以是实值或离散值。假设一个人有许多特征向量,其中包含潜在新员工的简历相关信​​息。回归问题的一个例子是预测该人在寻找新工作之前将在您的公司工作的时间长度。

Regression problems are those whose aim is to predict the value of an output variable given the values of several input variables. The value predicted can be real valued or discrete valued. Suppose one had many feature vectors consisting of vita-related information for a prospective new hire. An example of a regression problem would be to predict the length of time that person will stay with your company before looking for a new job.

分类问题和回归问题之间的界限并不精确。预测值来自有限集合的回归问题可以表述为分类问题,其中每个类别对应于有限预测值集合中的给定值。类似地,分类问题可以表述为回归问题,其中预测的输出值对应于类标签集。

The boundary between classification problems and regression problems is imprecise. A regression problem where the values predicted are from a finite set can be couched as a classification problem where each class corresponds to a given value in the finite set of predicted values. Similarly, a classification problem can be couched as a regression problem where the output values predicted correspond to the set of class labels.

用于监督学习的流行技术包括线性回归逻辑回归线性判别分析决策树k 最近邻神经网络。无监督学习方法的流行技术包括神经网络聚类降维。我们在本附录中仅考虑这些技术的一小部分。

Popular techniques used for supervised learning include linear regression, logistic regression, linear discriminant analysis, decision trees, k-nearest neighbor, and neural networks. Popular techniques for unsupervised learning approaches include neural networks, clustering, and dimensional reduction. We consider only a small sampling of these techniques in this appendix.

决策树决策树学习是一种预测技术,它使用树枝中包含的数据派生观察来得出有关树叶中包含的目标值的结论。根据输入变量值,做出一组分层决策。根据沿途提出的问题的答案,通过从根到叶跟踪树来找到输出变量值。第635页

Decision Trees Decision tree learning is a predictive technique that uses data-derived observations contained in the branches of the tree to develop conclusions about a target value contained in the leaves of the tree. Based on the input variable values, a set of hierarchical decisions are made. The output variable value is found by following a tree from the root to a leaf, based on answers to questions asked along the way.Page 635

一般来说,决策树可以是二元或非二元的,提出的问题可以是任意的,只要它们符合单个节点的子节点数量即可。对于本附录,对于某些输入变量x以及常量ab,我们将仅考虑具有x < axb形式的布尔问题的二叉树。如果问题的答案为 TRUE,我们会选择左边的孩子继续沿着树走,而如果答案为 FALSE,我们会选择右边的孩子。

In general, decision trees can be binary or nonbinary and the questions asked can be arbitrary, as long as they conform to the number of children at an individual node. For this appendix, we will consider only binary trees with Boolean questions of the form x < a or xb, for some input variable x and constants a and b. If the answer to a question is TRUE, we would choose the left child to continue our walk down the tree, while if it is FALSE, we would choose the right child.

给定输入和输出变量值的训练集,我们构建树,选择要在每个内部节点询问的布尔问题的类型。这通常以贪婪的方式完成,只是在给定节点询问哪个决策使误差平方和最小化。出于可视化目的,我们假设有两个输入变量x 1x 2,它们都是连续的。假设训练集的形式为 ( y , x 1 , x 2 ) 并且t 1 = (5.7, 2.3, 9.6), t 2 = (3.5, 1.1, 10), t 3 = (0.55, 3.6, 17.5 )。我们首先必须决定第一次分割是在x 1还是x 2上。我们选择误差最低的输入变量。

Given a training set of input and output variable values, we construct the tree choosing the type of Boolean question to ask at each internal node. This is usually done in a greedy fashion, simply asking, at a given node, which decision minimizes the sum of the squared errors. For visualization purposes, let us assume we have two input variables, x1 and x2, both of which are continuous. Suppose the training set is of the form (y, x1, x2) and is t1 = (5.7, 2.3, 9.6), t2 = (3.5, 1.1, 10), t3 = (0.55, 3.6, 17.5). We first must decide whether the first split will be on x1 or x2. We choose the input variable giving us the lowest error.

现在,树的每个节点都与训练集的一个子集相关联。例如,根与整个训练集相关联。如果根处的问题是x 1 < 1,则根的左子节点与空集关联,而根的右子节点与整个训练集关联。然而,如果根处的问题是x 1 < 1.8,则根的左子节点与t 2相关联,而根的右子节点与训练元组t 1t 3相关联。请注意,如果我们将 1.8 更改为 2.2,我们将具有相同的关联。然而,即使树是相同的,分割点的选择也会影响不在训练集中的输入值对的结果。

Now, each node of the tree is associated with a subset of the training set. For example, the root is associated with the entire training set. If the question at the root is x1 < 1, then the root’s left child is associated with the empty set and the root’s right child is associated with the entire training set. However, if the question at the root is x1 < 1.8, the root’s left child is associated with t2 and the root’s right child is associated with the training tuples t1 and t3. Note that if we change 1.8 to 2.2, we would have the same association. However, even if the tree is the same, the choice of the split point would affect the results for input value pairs which are not in the training set.

那么, x 1 < 1.8 分割产生的误差是多少?如果我们在此时停止,树将按如下方式使用。对于输入值对 ( c , d ),如果c < 1.8,我们将预测输出值为 3.5,而如果c ≥ 1.8,我们将预测输出值为 3.125,即 5.7 和 0.55 的平均值。对于此示例,左子项生成的平方误差为 0,而右子项生成的平方误差为 (3.125 − 5.7) 2 + (3.125 − 0.55) 2 ≅ 13.26。我们可以停在这里,或者在右侧进行进一步的细化,将平面划分为三个区域,每个区域与一个训练集元组相关联。有关两个不同分割的树、关联区域和错误的说明,请参见图A2.3 。

So, what is the error produced by the x1 < 1.8 split? If we stopped at this point, the tree would be used as follows. For an input value pair (c, d), if c < 1.8, we would predict the output value of 3.5, while if c ≥ 1.8, we would predict the output value of 3.125, the average of 5.7 and 0.55. For this example, the squared error produced from the left child is 0, while the squared error produced from the right child is (3.125 − 5.7)2 + (3.125 − 0.55)2 ≅ 13.26. We could stop here, or perform a further refinement on the right-hand side, producing a division of the plane into three regions, each associated with a single training set tuple. See Figure A2.3 for an illustration of the trees, associated regions, and errors for two different splits.

图 A2.3 不同分割的决策树示例(a) 决策树分割x 1 < 1.8 (b) 决策树分割x 2 < 15

Figure A2.3 Decision trees examples for different splits (a) Decision tree split x1 < 1.8 (b) Decision tree split x2 < 15

有许多有效的方法可以找到最佳树,其中包括何时以及如何分割区域以及何时停止分割包含多个训练集元组的区域。其中一些方法可以在 [Jam13] 中找到。

There are many efficient approaches to finding the best tree, which include when and how a region should be split and when to cease splitting a region containing more than one training set tuple. Some of these approaches can be found in [Jam13].

在杨等人中。[You18],阐述了决策树在软件工程研究中的应用,以解决即时缺陷预测问题。该技术可以预测小粒度的缺陷。预测代码更改更有可能引入缺陷。在本文中,证明决策树方法比许多其他学习技术更好地解决这个问题。决策树用于集成学习环境。这种类型的学习结合了许多并行学习器,最终的结果得到了很大的提高。

In Young et al. [You18], the use of decision trees in software engineering research is illustrated for the problem of just-in-time defect prediction. This technique predicts defects at small granularities. Code changes are predicted which are more likely to introduce defects. In this paper, it is demonstrated that the decision tree methodology is better than many other learning techniques for this problem. Decision trees are used in an ensemble learning environment. This type of learning combines many parallel learners in such a way that the final results are much improved.

最近邻k最近邻技术是一种估计未分类输入变量元组v在有限类集中的隶属概率的方法。它在概念上非常简单,但功能却非常强大。找到训练集中最接近给定点v的k 个点。对于给定的类c ,假设这些最接近的k个训练集点中有n 个点属于类c那么v属于c 的概率将为n / k。如果我们必须用单个类别来标记v,那么它将是概率最高的类别。k的值肯定会影响结果。已经发现,k值太小或太大都不能很好地执行。当k增加到最佳点时,误差会减小,但随着k进一步增加,误差会变大。示例见图A2.4:最近邻为1时,灰点被分类为黑色;有 3 个最近邻居,它被分类为白色;并且有 5 个最近邻,它被分类为白色。第636页

Nearest Neighbor The technique of k-nearest neighbor is an approach to estimate the probability of membership of an unclassified input variable tuple, v, in a finite set of classes. It is quite simple conceptually but can be very powerful. One finds the closest k points in the training set to the given point v. For a given class, c, suppose there are n points among these closest k training set points that belong to class c. Then the probability that v belongs to c would be n/k. If we had to label v with a single class, it would be the class with the highest probability. The value of k certainly affects the results. It has been found that values of k that are too small or too large don’t perform well. As k increases to its sweet spot, the error decreases, but as k further increases, the error gets larger. See Figure A2.4 for an example: with 1-nearest neighbor, the gray point is classified as black; with 3-nearest neighbors, it is classified as white; and with 5-nearest neighbors, it is classified as white.Page 636

图 A2.4 k-最近邻示例(k = 1,3,5)

Figure A2.4 k-Nearest neighbor example for k = 1,3,5

在黄等人。[Hua17],最近邻用于开发软件质量领域缺失数据的改进方法。缺失数据会给机器学习带来许多问题。有许多方法可以智能地估计该数据的值。

In Huang et al. [Hua17], nearest neighbor is used to develop an improved approach for missing data in the software quality area. Missing data causes many problems for machine learning. There are many approaches to intelligently estimate values for this data.

神经网络 神经网络体现了连接主义,一种由多个简单处理器(即脑细胞)在大规模并行环境中连接在一起组成的体系结构,支持许多并发进程,可用于解决许多问题。神经网络的强大之处在于,该方法将输出变量建模为输入变量的多个线性组合的非线性函数。更强大的神经网络有某种形式的反馈。要指定神经网络,我们必须指定节点的连接性、给定节点将其所有输入转换为输出的方式以及最终输出的生成方式。一般来说,神经网络通过所谓的反向传播技术(最速下降或遵循梯度方向)使用反馈来训练网络(估计执行回归所需的参数)。神经网络的一个弱点是很难确定特定参数如何与问题参数相关,从而导致神经网络做出给定决策的解释力较弱。第637页

Neural Networks Neural networks embody connectionism, an architecture consisting of connections of multiple simple processors (i.e., brain cells) together in a massively parallel environment, supporting many concurrent processes, that can be used to solve many problems. The power of neural networks results from the fact that this approach models the output variable as a nonlinear function of several linear combinations of the input variables. The more powerful neural networks have some form of feedback. To specify a neural network, we must specify the connectivity of the nodes, the way that a given node transforms all its inputs into an output, and how the final output is generated. In general, a neural network uses feedback through what is called a backpropagation technique (steepest descent or following the gradient direction) to train the network (estimate the parameters needed to carry out the regression). A weakness of neural networks is that it is hard to determine how particular parameters correlate with the parameters of the problem, leading to a weakness in explanatory power as to why a neural net has made a given decision.Page 637

聚类聚类是一种通用的数据驱动方法,用于查找在某种意义上相似的任何实体的组。找到一组,每个簇包含一组实体。这个想法是,同一集群中的两个实体高度相似,而不同集群中的两个实体则不那么相似。通常由研究者来弄清楚相似性的确切含义。在本附录的上下文中,实体将是特征向量,并且使用向量之间的距离函数来定义相似性。向量之间的距离越小,它们就越相似。聚类算法有数百种,并且不能保证您会从每种算法中获得相同的聚类。簇可以有不同的形状,一些算法对于凸形状效果更好,而另一些算法可以放宽这种条件。有些算法是专门为高维空间设计的,而另一些则不是。

Clustering Clustering is a general data-driven approach to find groups of any entities that are similar in some sense. A group of clusters are found, each cluster containing a set of entities. The idea is that two entities in the same cluster are highly similar, while two entities, each in different clusters, are not as similar. It is generally up to the investigator to figure out what exactly is meant by similarity. In the context of this appendix, the entities will be feature vectors and similarity is defined using a distance function between vectors. Vectors having a smaller distance between them will be more similar. There are hundreds of clustering algorithms, and there is no guarantee that you will get the same clustering from each of them. Clusters can have different shapes, and some algorithms work better with convex shapes, while others can relax this condition. Some algorithms are specifically designed for high-dimensional spaces, while others aren’t.

降维 降维是指减少输入特征向量的长度。在许多重要的环境中,这些向量的大小可能会变得相当大。例如,在自然语言处理中,每个词汇在向量中都有自己的位置。因此,这些向量具有 5,000 到 50,000 个元素是很常见的。因此,降低维度将加快学习过程。最初,在计算机科学的多个学科中,这是降维的唯一原因。然而,人们很快发现,降低输入特征向量的维度也提高了下游应用程序中使用的许多底层算法的性能。

Dimensional Reduction By dimensional reduction, we mean decreasing the lengths of the input feature vectors. In many important environments, the size of these vectors can get quite large. In natural language processing, for example, each vocabulary word has its own position in the vector. It is quite common, therefore, for these vectors to have from 5,000 to 50,000 elements. Reducing the dimensionality would thus speed up the learning process. Initially, in several disciplines of computer science, this was the sole reason for dimensionality reduction. However, it was soon discovered that reducing the dimensionality of the input feature vectors also improved the performance of many of the underlying algorithms used in downstream applications.

第638页

Page 638

计算智能基于搜索软件工程_ _ _ _

COMPUTATIONAL INTELLIGENCE AND SEARCH-BASED SOFTWARE ENGINEERING

计算智能通常是指系统(硬件和软件)从收集的有关该任务的一组数据中学习特定任务的能力。一些人将计算计算归类为粒度计算(模糊集、粗糙集、概率推理)、神经计算(神经网络)、进化计算(遗传编程、遗传算法和群体智能)和人工生命(人工免疫系统)的组合。 )。这些方法可用于优化、分类、搜索和回归。

Computational intelligence generally refers to the ability of a system (hardware and software) to learn a specific task from a set of data collected about that task. Some classify computational computing as a combination of granular computing (fuzzy sets, rough sets, probabilistic reasoning), neuro-computing (neural nets), evolutionary computing (genetic programming, genetic algorithms, and swarm intelligence), and artificial life (artificial immune systems). These approaches can be used for optimization, classification, search, and regression.

在基于搜索的软件工程中,基于计算智能的技术已用于各种优化。例如,有论文[Oun17]使用遗传算法进行多目标优化,快速搜索所有可能的代码重构的空间并推荐最佳选项,每个选项都说明了输入变量之间的一些特定权衡,但仍然是局部最优的。事实证明,这些方法也可用于构建预测模型 [Mal17]。

In search-based software engineering, computational intelligence–based techniques have been used for various sorts of optimizations. For example, there are papers [Oun17] using genetic algorithms for multi-objective optimization that quickly search the space of all possible code refactorings and recommend the best options, each option illustrating some particular trade-offs among the input variables, but still locally optimal. It has been shown that these approaches can also be used to build predictive models [Mal17].

数据科学、机器学习和基于搜索的软件工程的融合可能会在软件的指定、设计、编码和测试方式方面带来令人兴奋的突破。时间会证明一切。

The merger of data science, machine learning, and search-based software engineering may lead to exciting breakthroughs in the way software is specified, designed, coded, and tested. Time will tell.

1密歇根大学迪尔伯恩分校计算机与信息科学系。

1 Computer and Information Science Department, University of Michigan, Dearborn.

2请参阅 https://en.wikipedia.org/wiki/Data_wrangling。

2 See https://en.wikipedia.org/wiki/Data_wrangling.

3 https://hive.apache.org/。

3 https://hive.apache.org/.

4 https://spark.apache.org/。

4 https://spark.apache.org/.

5 https://hadoop.apache.org/。

5 https://hadoop.apache.org/.

第639页

Page 639

参考_

References

[Abb83]

[Abb83]

Abbott, R.,“通过非正式英语描述进行程序设计”,CACM,卷。26、没有。11,1983 年 11 月,第 892-894 页。

Abbott, R., “Program Design by Informal English Descriptions,” CACM, vol. 26, no. 11, November 1983, pp. 892–894.

[阿卜杜勒16]

[Abd16]

Abdessalem, R. 等人,“使用多目标搜索和神经网络测试高级驾驶员辅助系统”,第 31 届IEEE/ACM 国际自动化软件工程会议论文集, ACM,2016 年,第 63-74 页。

Abdessalem, R., et al., “Testing Advanced Driver Assistance Systems Using Multi-Objective Search and Neural Networks,” Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering, ACM, 2016, pp. 63–74.

[4月17日]

[Abr17]

Abreu, L.,“移动应用程序的用户体验设计模式:哪个和为什么”,2017 年,可访问 https://www.raywenderlich.com/167174/design-patterns-mobile-apps-which-why。

Abreu, L., “UX Design Patterns for Mobile Apps: Which and Why,” 2017, available at https://www.raywenderlich.com/167174/design-patterns-mobile-apps-which-why.

[ACM12]

[ACM12]

ACM/IEEE-CS 联合工作组,《软件工程道德规范和专业实践》, 2012 年,可访问 https://ethics.acm.org/code-of-ethics/software-engineering-code。

ACM/IEEE-CS Joint Task Force, Software Engineering Code of Ethics and Professional Practice, 2012, available at https://ethics.acm.org/code-of-ethics/software-engineering-code.

[ACM18]

[ACM18]

ACM 道德和职业行为准则, 2018 年,请访问 https://ethics.acm.org/。

ACM Code of Ethics and Professional Conduct, 2018, available at https://ethics.acm.org/.

[第18幕]

[Act18]

ActiveWizards,“2018 年数据科学领域前 20 个 Python 库”,2018 年 2 月 13 日。2018 年 10 月从 ActiveWizards 检索:https://activewizards.com/blog/top-20-python-libraries-for-data-science-in -2018/。

ActiveWizards, “Top 20 Python Libraries for Data Science in 2018,” February 13, 2018. Retrieved October 2018 from ActiveWizards: https://activewizards.com/blog/top-20-python-libraries-for-data-science-in-2018/.

[阿达16]

[Ada16]

Adams, B. 和 S. McIntosh,“现代发布工程简而言之——为什么研究人员应该关心”,2016 年 IEEE 第 23 届软件分析、演化和再工程国际会议 (SANER), 2016 年 3 月,第 78-90 页。

Adams, B., and S. McIntosh, “Modern Release Engineering in a Nutshell—Why Researchers Should Care,” 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), March 2016, pp. 78–90.

[亚足联88]

[AFC88]

软件风险消除,AFCS/AFLC 小册子 800-45,美国空军,1988 年 9 月 30 日。

Software Risk Abatement, AFCS/AFLC Pamphlet 800-45, U.S. Air Force, September 30, 1988.

[阿吉17]

[Agi17]

敏捷联盟主页,可访问 https://www.agilealliance.org。

Agile Alliance home page, available at https://www.agilealliance.org.

[航空99]

[Air99]

艾尔利委员会,“基于绩效的管理:基于 16 点计划和相关指标的项目经理指南”,报告草案,1999 年 3 月 8 日。

Airlie Council, “Performance Based Management: The Program Manager’s Guide Based on the 16-Point Plan and Related Metrics,” Draft Report, March 8, 1999.

[白蛋白10]

[Alb10]

Alberts, C. 等人,“软件安全集成测量和分析框架”,CMU/SEI-2010-TN-025。卡内基梅隆大学软件工程学院,2010 年,可访问 http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9369。

Alberts, C., et al., “Integrated Measurement and Analysis Framework for Software Security,” CMU/SEI-2010-TN-025. Software Engineering Institute, Carnegie Mellon University, 2010, available at http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9369.

[麦酒02]

[Ale02]

Alexander, I.,“误用案例有助于引发非功能性需求”,2002 年,可从 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.9670&rep=rep1&type=pdf 获取。

Alexander, I., “Misuse Cases Help to Elicit Non-Functional Requirements,” 2002, available at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.9670&rep=rep1&type=pdf.

[麦酒03]

[Ale03]

Alexander, I.,“误用案例:具有敌意意图的用例”,IEEE Software,卷。20、没有。1,2003 年,第 58-66 页。

Alexander, I., “Misuse Cases: Use Cases with Hostile Intent,” IEEE Software, vol. 20, no. 1, 2003, pp. 58–66.

[麦芽酒11]

[Ale11]

亚历山大,I.,“血腥、疼痛,还是什么?” IEEE 软件,卷。28、没有。1,2011 年 1 月至 2 月,第 8-10 页。

Alexander, I., “Gore, Sore, or What?” IEEE Software, vol. 28, no. 1, January–February 2011, pp. 8–10.

[麦芽酒17]

[Ale17]

Alebrahim, A.,“第 1 阶段:上下文启发和问题分析”,弥合需求工程和软件架构之间的差距, Springer Vieweg,威斯巴登,2017 年,可访问 https://doi.org/10.1007/978-3-658 -17694-5_4。

Alebrahim, A., “Phase 1: Context Elicitation & Problem Analysis,” Bridging the Gap between Requirements Engineering and Software Architecture, Springer Vieweg, Wiesbaden, 2017, available at https://doi.org/10.1007/978-3-658-17694-5_4.

[麦芽酒77]

[Ale77]

Alexander, C.,《一种模式语言》,牛津大学出版社,1977 年。

Alexander, C., A Pattern Language, Oxford University Press, 1977.

[麦芽酒79]

[Ale79]

Alexander, C.,《永恒的建筑方式》,牛津大学出版社,1979 年。

Alexander, C., The Timeless Way of Building, Oxford University Press, 1979.

[阿尔赫13]

[Alh13]

Alhusain, S.,“迈向基于机器学习的设计模式识别”,第 13 届英国计算智能研讨会论文集, 2013 年 9 月,第 244-251 页。

Alhusain, S., “Towards Machine Learning Based Design Pattern Recognition,” Proceedings of 13th UK Workshop on Computational Intelligence, September 2013, pp. 244–251.

[阿里14]

[Ali14]

Alice, G. 和 Mead, N.,“使用恶意软件分析为移动平台定制 SQUARE”,CMU/SEI-2014-TN-018。卡内基梅隆大学软件工程学院,2014 年,网址为:http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=425994。

Alice, G., and Mead, N., “Using Malware Analysis to Tailor SQUARE for Mobile Platforms,” CMU/SEI-2014-TN-018. Software Engineering Institute, Carnegie Mellon University, 2014, available at http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=425994.

[阿里18]

[Ali18]

Alizadeh, V.、M. Kessentini、W. Mkaouer、M. Ocinneide、A. Ouni 和 Y. Cai,“基于交互式和动态搜索的软件重构建议方法”,IEEE 软件工程汇刊,2018 年可用网址:https://ieeexplore.ieee.org/document/8477161。

Alizadeh, V., M. Kessentini, W. Mkaouer, M. Ocinneide, A. Ouni, and Y. Cai, “An Interactive and Dynamic Search-Based Approach to Software Refactoring Recommendations,” IEEE Transactions on Software Engineering, 2018, available at https://ieeexplore.ieee.org/document/8477161.

[全部08]

[All08]

Allen, JH 等人,软件安全工程:项目经理指南, Addison-Wesley Professional,2008 年。

Allen, J. H., et al., Software Security Engineering: A Guide for Project Managers, Addison-Wesley Professional, 2008.

[全部14]

[All14]

Alleman, G.,基于绩效的项目管理:提高项目成功的可能性, AMACOM,2014 年。

Alleman, G., Performance-Based Project Management: Increasing the Probability of Project Success, AMACOM, 2014.

[Als18]

[Als18]

Alshahwan, N. 等人,“在 Facebook 上使用 Sapienz 部署基于搜索的软件工程”,基于搜索的软件工程 SSBSE 2018。计算机科学讲义,T. Colanzi 和 P. McMinn(编辑),卷。11036,施普林格,2018。

Alshahwan, N., et al., “Deploying Search Based Software Engineering with Sapienz at Facebook,” Search-Based Software Engineering SSBSE 2018. Lecture Notes in Computer Science, T. Colanzi and P. McMinn (eds.), vol. 11036, Springer, 2018.

[Amb02]

[Amb02]

第640页Ambler, S. 和 R. Jeffries,《敏捷建模》, Wiley,2002 年。

Page 640Ambler, S., and R. Jeffries, Agile Modeling, Wiley, 2002.

[安布04]

[Amb04]

Ambler, S.,“检查变革成本曲线”,《对象入门》,第 3 版,剑桥大学出版社,2004 年。

Ambler, S., “Examining the Cost of Change Curve,” in The Object Primer, 3rd ed., Cambridge University Press, 2004.

[安布95]

[Amb95]

Ambler, S.,“使用用例”,软件开发, 1995 年 7 月,第 53-61 页。

Ambler, S., “Using Use-Cases,” Software Development, July 1995, pp. 53–61.

[安布98]

[Amb98]

Ambler, S.,流程模式:使用对象技术构建大型系统,剑桥大学出版社/SIGS 图书,1998 年。

Ambler, S., Process Patterns: Building Large-Scale Systems Using Object Technology, Cambridge University Press/SIGS Books, 1998.

[放大器13]

[Amp13]

Ampatzoglou, A. 等人,“构建和挖掘设计模式实例存储库:实践和研究的好处”,娱乐计算,卷。4,2013 年 4 月,第 131-142 页。

Ampatzoglou, A., et al., “Building and Mining a Repository of Design Pattern Instances: Practical and Research Benefits,” Entertainment Computing, vol. 4, April 2013, pp. 131–142.

[和05]

[And05]

Andreou, A. 等人,“移动商务服务和应用程序设计和开发的关键问题”,国际移动通信杂志,卷。3、没有。3,2005 年 3 月,第 303-323 页。

Andreou, A., et al., “Key Issues for the Design and Development of Mobile Commerce Services and Applications,” International Journal of Mobile Communications, vol. 3, no. 3, March 2005, pp. 303–323.

[和06]

[And06]

Andrews, M. 和 J. Whittaker,《如何破解 Web 软件:Web 应用程序和 Web 服务的功能和安全测试》, Addison-Wesley,2006 年。

Andrews, M., and J. Whittaker, How to Break Web Software: Functional and Security Testing of Web Applications and Web Services, Addison-Wesley, 2006.

[和16]

[And16]

Anderson, D. 和 A. Carmichael,《Essential Kanban Condensed》,精益看板大学出版社,2016 年,可在eankanban.com/guide 获取。

Anderson, D., and A. Carmichael, Essential Kanban Condensed, Lean Kanban University Press, 2016, available at leankanban.com/guide.

[ANS87]

[ANS87]

ANSI/ASQC A3-1987,质量体系术语, 1987。

ANSI/ASQC A3-1987, Quality Systems Terminology, 1987.

[应用程序00]

[App00]

Appleton, B.,“模式和软件:基本概念和术语”,2000 年 2 月,可从 www.cmcrossroads.com/bradapp/docs/patterns-intro.html 获取。

Appleton, B., “Patterns and Software: Essential Concepts and Terminology,” February 2000, available at www.cmcrossroads.com/bradapp/docs/patterns-intro.html.

[应用13]

[App13]

Apple Computer,辅助功能, 2013 年,可访问 www.apple.com/accessibility/。

Apple Computer, Accessibility, 2013, available at www.apple.com/accessibility/.

[阿尔02]

[Arl02]

Arlow, J. 和 I. Neustadt,《UML 和统一过程》, Addison-Wesley,2002 年。

Arlow, J., and I. Neustadt, UML and the Unified Process, Addison-Wesley, 2002.

[阿恩11]

[Arn11]

Arnuphaptairong, T.,“软件项目风险十大列表:文献调查的证据”,国际工程师和计算机科学家多次会议论文集,卷。I,IMECS 2011,2011 年 3 月。

Arnuphaptrairong, T., “Top Ten Lists of Software Project Risks: Evidence from the Literature Survey,” Proceedings International Multi-Conference of Engineers and Computer Scientists, vol. I, IMECS 2011, March 2011.

[ISO17]

[ISO17]

ISO/IEC/IEEE 24765:2017(E),ISO/IEC/IEEE 国际标准:系统和软件工程—词汇,可从 https://standards.ieee.org/findstds/standard/24765-2017.html 获取。

ISO/IEC/IEEE 24765:2017(E), ISO/IEC/IEEE International Standard: Systems and Software Engineering—Vocabulary, available at https://standards.ieee.org/findstds/standard/24765-2017.html.

[阿斯特04]

[Ast04]

Astels, D.,测试驱动开发:实用指南, Prentice Hall,2004 年。

Astels, D., Test Driven Development: A Practical Guide, Prentice Hall, 2004.

[咩10]

[Baa10]

Baaz, A. 等人,“欣赏经验教训”,IEEE Software,卷。27、没有。4,2010 年 7 月至 8 月,第 72-79 页。

Baaz, A., et al., “Appreciating Lessons Learned,” IEEE Software, vol. 27, no. 4, July–August, 2010, pp. 72–79.

[巴巴09]

[Bab09]

Babar, M. 和 I. Groton,“软件架构评论:实践状况”,IEEE 计算机,卷。42、没有。6,2009 年 6 月,第 1-8 页。

Babar, M., and I. Groton, “Software Architecture Review: The State of Practice,” IEEE Computer, vol. 42, no. 6, June 2009, pp. 1–8.

[巴巴86]

[Bab86]

Babich,华盛顿州,软件配置管理, Addison-Wesley,1986 年。

Babich, W. A., Software Configuration Management, Addison-Wesley, 1986.

[裴98]

[Bae98]

Baetjer, Jr., H.,《软件作为资本》, IEEE 计算机协会出版社,1998 年,第 11 页。85.

Baetjer, Jr., H., Software as Capital, IEEE Computer Society Press, 1998, p. 85.

[巴杰11]

[Baj11]

Bajdor, P. 和 L. Dragolea,“游戏化作为改善企业风险管理的工具”,阿普伦大学年鉴系列 Oeconomica,卷。2、没有。2011 年 10 月 13 日,可查阅 http://www.oeconomica.uab.ro/upload/lucrari/1320112/38.pdf。

Bajdor, P., and L. Dragolea, “The Gamification as a Tool to Improve Risk Management in the Enterprise,” Annales Universitatis Apulensis Series Oeconomica, vol. 2, no. 13, 2011, available at http://www.oeconomica.uab.ro/upload/lucrari/1320112/38.pdf.

[酒吧06]

[Bar06]

Baresi, L.、E. DiNitto 和 C. Ghezzi,“走向开放世界软件:问题和挑战”,IEEE 计算机,卷。39,没有。10,2006 年 10 月,第 36-43 页。

Baresi, L., E. DiNitto, and C. Ghezzi, “Toward Open-World Software: Issues and Challenges,” IEEE Computer, vol. 39, no. 10, October 2006, pp. 36–43.

[巴斯12]

[Bas12]

Bass, L.、P. Clements 和 R. Kazman,《软件架构实践》,第 3 版,Addison-Wesley,2012 年。

Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, 3rd ed., Addison-Wesley, 2012.

[蝙蝠18]

[Bat18]

Batarseh, F. 和 A. Gonzalez,“通过数据分析预测敏捷软件开发中的失败”,软件质量期刊,卷。26、没有。1,2018 年 3 月,第 49-66 页。

Batarseh, F., and A. Gonzalez, “Predicting Failures in Agile Software Development through Data Analytics,” A Software Quality Journal, vol. 26, no. 1, March 2018, pp. 49–66.

[BEC99]

[Bec99]

Beck, K.,《极限编程解释:拥抱变化》, Addison-Wesley,1999 年。

Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

[BEC01]

[Bec01]

Beck, K. 等人,“敏捷软件开发宣言”,2001 年,可从 www.agilemanifesto.org/ 获取。

Beck, K., et al., “Manifesto for Agile Software Development,” 2001, available at www.agilemanifesto.org/.

[BEC04a]

[Bec04a]

Beck, K.,《极限编程解释:拥抱变化》,第二版,Addison-Wesley,2004 年。

Beck, K., Extreme Programming Explained: Embrace Change, 2nd ed., Addison-Wesley, 2004.

[BEC04b]

[Bec04b]

Beck, K.,测试驱动开发:举例,第二版,Addison-Wesley,2004 年。

Beck, K., Test-Driven Development: By Example, 2nd ed., Addison-Wesley, 2004.

[蜜蜂99]

[Bee99]

Beedle, M. 等人,“SCRUM:超高效软件开发的扩展模式语言”,包含在《程序设计模式语言 4》中, Addison-Wesley Longman,1999 年,可从 http://jeffsutherland.com/scrum/ 获取scrum_plop.pdf。

Beedle, M., et al., “SCRUM: An Extension Pattern Language for Hyperproductive Software Development,” included in Pattern Languages of Program Design 4, Addison-Wesley Longman, 1999, available at http://jeffsutherland.com/scrum/scrum_plop.pdf.

[求10]

[Beg10]

Begel, A.、R. DeLine 和 T. Zimmermann,“软件工程的社交媒体”,Proceedings FoSER 2010, ACM,2010 年 11 月。

Begel, A., R. DeLine, and T. Zimmermann, “Social Media for Software Engineering,” Proceedings FoSER 2010, ACM, November 2010.

[北90]

[Bei90]

Beizer, B.,软件测试技术,第二版,Van Nostrand-Reinhold,1990 年。

Beizer, B., Software Testing Techniques, 2nd ed., Van Nostrand-Reinhold, 1990.

[北95]

[Bei95]

Beizer, B.,黑盒测试, Wiley,1995。

Beizer, B., Black-Box Testing, Wiley, 1995.

[贝尔17]

[Bel17]

Bell, L. 等人,敏捷应用程序安全, O'Reilly Media,2017 年。

Bell, L., et al., Agile Application Security, O’Reilly Media, 2017.

[贝尔14]

[Bel14]

Bellomo, S.、P. Krutchen、R. Nord 和 I. Ozkaya,“如何敏捷地构建敏捷架构”,Cutter IT Journal, 2014 年 2 月,第 10-15 页。

Bellomo, S., P. Krutchen, R. Nord, and I. Ozkaya, “How to Agilely Architect an Agile Architecture,” Cutter IT Journal, February 2014, pp. 10–15.

[本10a]

[Ben10a]

第641页Bennett, S.、S. McRobb 和 R. Farmer,《使用 UML 进行面向对象的分析和设计》,第 4 版,McGraw-Hill,2010 年。

Page 641Bennett, S., S. McRobb, and R. Farmer, Object-Oriented Analysis and Design Using UML, 4th ed., McGraw-Hill, 2010.

[本10b]

[Ben10b]

Benaroch, M. 和 A. Appari,“软件开发风险因素的财务定价”,IEEE Software,卷。27、没有。3,2010 年 9 月至 10 月,第 65-73 页。

Benaroch, M., and A. Appari, “Financial Pricing of Software Development Risk Factors,” IEEE Software, vol. 27, no. 3, September–October 2010, pp. 65–73.

[贝尔80]

[Ber80]

Bersoff, E.、V. Henderson 和 S. Siegel,《软件配置管理》, Prentice Hall,1980 年。

Bersoff, E., V. Henderson, and S. Siegel, Software Configuration Management, Prentice Hall, 1980.

[贝尔93]

[Ber93]

Berard, E.,面向对象软件工程论文,卷。1,艾迪生-韦斯利,1993 年。

Berard, E., Essays on Object-Oriented Software Engineering, vol. 1, Addison-Wesley, 1993.

[宾94]

[Bin94]

Binder, R.,“测试面向对象的系统:状态报告”,《美国程序员》,卷。7、没有。4,1994 年 4 月,第 23-28 页。

Binder, R., “Testing Object-Oriented Systems: A Status Report,” American Programmer, vol. 7, no. 4, April 1994, pp. 23–28.

[宾99]

[Bin99]

Binder, R.,测试面向对象系统:模型、模式和工具, Addison-Wesley,1999 年。

Binder, R., Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison-Wesley, 1999.

[比尔98]

[Bir98]

Biró, M. 和 T. Remzsö,“软件流程改进的商业动机”,ERCIM 新闻,第 1 期。1998 年 1 月 32 日,可访问 www.ercim.org/publication/Ercim_News/enw32/biro.html。

Biró, M., and T. Remzsö, “Business Motivations for Software Process Improvement,” ERCIM News, no. 32, January 1998, available at www.ercim.org/publication/Ercim_News/enw32/biro.html.

[比斯02]

[Bis02]

Bishop, M.,计算机安全:艺术与科学,Addison-Wesley Professional,2002 年。

Bishop, M., Computer Security: Art and Science, Addison-Wesley Professional, 2002.

[Bjø16]

[Bjø16]

Bjørnson, F. 和 K. Vestues,“大规模敏捷开发中的知识共享和流程改进”,XP2016 科学研讨会论文集(XP '16 研讨会)。ACM,纽约,纽约,2016 年,第 7 条。

Bjørnson, F., and K. Vestues, “Knowledge Sharing and Process Improvement in Large-Scale Agile Development,” Proceedings Scientific Workshop of XP2016 (XP ’16 Workshops). ACM, New York, NY, 2016, Article 7.

[布莱10]

[Bla10]

Blair, S. 等人,“责任驱动架构”,IEEE 软件,卷。27、没有。3,2010 年 3 月至 4 月,第 26-32 页。

Blair, S., et al., “Responsibility-Driven Architecture,” IEEE Software, vol. 27, no. 3, March–April 2010, pp. 26–32.

[Boe01a]

[Boe01a]

Boehm, B.,“螺旋模型作为进化软件获取的工具”,CrossTalk, 2001 年 5 月,可从 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.642.8250&rep=rep1&type 获取=pdf。

Boehm, B., “The Spiral Model as a Tool for Evolutionary Software Acquisition,” CrossTalk, May 2001, available at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.642.8250&rep=rep1&type=pdf.

[Boe01b]

[Boe01b]

Boehm, B. 和 V. Basili,“软件缺陷减少前 10 名列表”,IEEE 计算机,卷。34、没有。1,2001 年 1 月,第 135-137 页。

Boehm, B., and V. Basili, “Software Defect Reduction Top 10 List,” IEEE Computer, vol. 34, no. 1, January 2001, pp. 135–137.

[京东方08]

[Boe08]

Boehm, B.,“在软件世纪中做出改变”,IEEE 计算机,卷。41、没有。3,2008 年 3 月,第 32-38 页。

Boehm, B., “Making a Difference in the Software Century,” IEEE Computer, vol. 41, no. 3, March 2008, pp. 32–38.

[Boe81]

[Boe81]

Boehm, B.,软件工程经济学, Prentice Hall,1981。

Boehm, B., Software Engineering Economics, Prentice Hall, 1981.

[Boe88]

[Boe88]

Boehm, B.,“软件开发和增强的螺旋模型”,计算机,卷。21、没有。5,1988 年 5 月,第 61-72 页。

Boehm, B., “A Spiral Model for Software Development and Enhancement,” Computer, vol. 21, no. 5, May 1988, pp. 61–72.

[Boe89]

[Boe89]

Boehm, BW,软件风险管理, IEEE 计算机协会出版社,1989 年。

Boehm, B. W., Software Risk Management, IEEE Computer Society Press, 1989.

[Boe96]

[Boe96]

Boehm, B.,“锚定软件流程”,IEEE Software,卷。13、没有。4,1996 年 7 月,第 73-82 页。

Boehm, B., “Anchoring the Software Process,” IEEE Software, vol. 13, no. 4, July 1996, pp. 73–82.

[Boe98]

[Boe98]

Boehm, B.,“使用 WINWIN 螺旋模型:案例研究”,计算机,卷。31、没有。7,1998 年 7 月,第 33-44 页。

Boehm, B., “Using the WINWIN Spiral Model: A Case Study,” Computer, vol. 31, no. 7, July 1998, pp. 33–44.

[博00]

[Boh00]

Bohl, M. 和 M. Rynn,《结构化设计工具:编程逻辑简介》,第 5 版,Prentice Hall,2000 年。

Bohl, M., and M. Rynn, Tools for Structured Design: An Introduction to Programming Logic, 5th ed., Prentice Hall, 2000.

[博66]

[Boh66]

Bohm, C. 和 G. Jacopini,“流程图、图灵机和只有两种形成规则的语言”,CACM,卷。9、不。5,1966 年 5 月,第 366-371 页。

Bohm, C., and G. Jacopini, “Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules,” CACM, vol. 9, no. 5, May 1966, pp. 366–371.

[博伊04]

[Boi04]

Boiko, B.,《内容管理圣经》,第二版,Wiley,2004 年。

Boiko, B., Content Management Bible, 2nd ed., Wiley, 2004.

[嘘05]

[Boo05]

Booch, G.、J. Rumbaugh 和 I. Jacobsen,《统一建模语言用户指南》,第二版,Addison-Wesley,2005 年。

Booch, G., J. Rumbaugh, and I. Jacobsen, The Unified Modeling Language User Guide, 2nd ed., Addison-Wesley, 2005.

[嘘11a]

[Boo11a]

Booch, G.,“主导设计”,IEEE 软件,卷。28、没有。2,2011 年 1 月至 2 月,第 8-9 页。

Booch, G., “Dominant Design,” IEEE Software, vol. 28, no. 2, January–February 2011, pp. 8–9.

[嘘11b]

[Boo11b]

Booch, G.,“给我画一张图”,IEEE 软件,卷。28、没有。1,2011 年 1 月至 2 月,第 6-7 页。

Booch, G., “Draw Me a Picture,” IEEE Software, vol. 28, no. 1, January–February 2011, pp. 6–7.

[博斯00]

[Bos00]

Bosch, J.,软件架构的设计和使用, Addison-Wesley,2000 年。

Bosch, J., Design & Use of Software Architectures, Addison-Wesley, 2000.

[博斯11]

[Bos11]

Bose, B. 等人,“将智能手机转变为汽车应用平台”,IEEE 计算机,卷。44,没有。5,2011 年 5 月,第 28-29 页。

Bose, B., et al., “Morphing Smartphones into Automotive Application Platforms,” IEEE Computer, vol. 44, no. 5, May 2011, pp. 28–29.

[布雷02]

[Bre02]

Breen, P.,“揭露‘足够好’软件的谬误”,informit.com,2002 年 2 月 1 日,网址为:http://www.informit.com/articles/article.aspx?p=25141&seqNum=3。

Breen, P., “Exposing the Fallacy of ‘Good Enough’ Software,” informit.com, February 1, 2002, available at http://www.informit.com/articles/article.aspx?p=25141&seqNum=3.

[布里09]

[Bri09]

Briand, L.,“模型驱动开发和基于搜索的软件工程:研究协同的机会”,2009 年第一届基于搜索的软件工程国际研讨会,温莎,2009 年。

Briand, L., “Model-Driven Development and Search-Based Software Engineering: An Opportunity for Research Synergy,” 2009 1st International Symposium on Search Based Software Engineering, Windsor, 2009.

[布里13]

[Bri13]

Briers, B.,“项目管理的游戏化”。2013 年PMI ®全球大会——北美,路易斯安那州新奥尔良。宾夕法尼亚州纽敦广场:项目管理研究所,2013 年,网址:https://www.pmi.org/learning/library/gamification-project-management-5949。

Briers, B., “The Gamification of Project Management.” PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute, 2013, available at https://www.pmi.org/learning/library/gamification-project-management-5949.

[兄弟06]

[Bro06]

Broy, M.,“信息学中的‘重大挑战’:工程软件密集型系统”,IEEE 计算机,卷。39,没有。10,2006 年 10 月,第 72-80 页。

Broy, M., “The ‘Grand Challenge’ in Informatics: Engineering Software Intensive Systems,” IEEE Computer, vol. 39, no. 10, October 2006, pp. 72–80.

[兄弟10a]

[Bro10a]

第642页Brown, N.、R. Nord 和 I. Ozkaya,“通过架构实现敏捷性”,Crosstalk, 2010 年 11 月至 12 月,可访问 https://apps.dtic.mil/dtic/tr/fulltext/u2/a552111。 pdf。

Page 642Brown, N., R. Nord, and I. Ozkaya, “Enabling Agility through Architecture,” Crosstalk, November–December 2010, available at https://apps.dtic.mil/dtic/tr/fulltext/u2/a552111.pdf.

[兄弟10b]

[Bro10b]

Broy, M. 和 R. Reussner,“软件架构评论:实践状况”,IEEE 计算机,卷。43,没有。10,2010 年 6 月,第 88-91 页。

Broy, M., and R. Reussner, “Software Architecture Review: The State of Practice,” IEEE Computer, vol. 43, no. 10, June 2010, pp. 88–91.

[兄弟12]

[Bro12]

Brown, A.,《开源应用程序架构》, lulu.com,2012 年。

Brown, A., The Architecture of Open Source Applications, lulu.com, 2012.

[兄弟98]

[Bro98]

Brown, WJ 等人,AntiPatterns — 危机中的重构软件、架构和项目, Wiley,1998 年。

Brown, W. J., et al., AntiPatterns—Refactoring Software, Architectures, and Projects in Crisis, Wiley, 1998.

[芽96]

[Bud96]

Budd, T.,《面向对象编程简介》,第二版,Addison-Wesley,1996 年。

Budd, T., An Introduction to Object-Oriented Programming, 2nd ed., Addison-Wesley, 1996.

[布尔16]

[Bur16]

Burns, A.、B. Umbaugh 和 C. Dunn,“移动软件开发生命周期简介”,2016 年,可访问 https://docs.microsoft.com/en-us/xamarin/cross-platform/get-启动/移动 sdlc 简介。

Burns, A., B. Umbaugh, and C. Dunn, “Introduction to the Mobile Software Development Lifecycle,” 2016, available at https://docs.microsoft.com/en-us/xamarin/cross-platform/get-started/introduction-to-mobile-sdlc.

[公交车07]

[Bus07]

Buschmann, F. 等人,面向模式的软件架构,模式系统, Wiley,2007 年。

Buschmann, F., et al., Pattern-Oriented Software Architecture, A System of Patterns, Wiley, 2007.

[巴士10b]

[Bus10b]

Buschmann, F. 和 K. Henley,“软件架构的五个注意事项,第 1 部分”,IEEE Software,卷。27、没有。3,2010 年 5 月至 6 月,第 63-65 页。

Buschmann, F., and K. Henley, “Five Considerations for Software Architecture, Part 1,” IEEE Software, vol. 27, no. 3, May–June 2010, pp. 63–65.

[巴士10c]

[Bus10c]

Buschmann, F. 和 K. Henley,“软件架构的五个注意事项,第 2 部分”,IEEE Software,卷。27、没有。4,2010 年 7 月至 8 月,第 12-14 页。

Buschmann, F., and K. Henley, “Five Considerations for Software Architecture, Part 2,” IEEE Software, vol. 27, no. 4, July–August 2010, pp. 12–14.

[Cac02]

[Cac02]

Cachero, C. 等人,“概念导航分析:独立于设备和平台的导航规范”,第二届面向网络技术国际研讨会论文集, 2002 年 6 月,可从 http://gplsi.dlsi.ua 获取。 es/iwad/ooh_project/papers/iwwost02.pdf。

Cachero, C., et al., “Conceptual Navigation Analysis: A Device and Platform Independent Navigation Specification,” Proceedings of the 2nd International Workshop on Web-Oriented Technology, June 2002, available at http://gplsi.dlsi.ua.es/iwad/ooh_project/papers/iwwost02.pdf.

[车08]

[Car08]

Carrasco, M.,“高性能软件开发团队的 7 个关键属性”,2008 年 6 月 30 日,可访问 http://www.realsoftwaredevelopment.com/7-key-attributes-of-high-performance-software-development-团队/。

Carrasco, M., “7 Key Attributes of High Performance Software Development Teams,” June 30, 2008, available at http://www.realsoftwaredevelopment.com/7-key-attributes-of-high-performance-software-development-teams/.

[90号车]

[Car90]

Card, D. 和 R. Glass,《测量软件设计质量》, Prentice Hall,1990 年。

Card, D., and R. Glass, Measuring Software Design Quality, Prentice Hall, 1990.

[Cav78]

[Cav78]

Cavano, J. 和 J. McCall,“软件质量测量框架”,ACM 软件质量保证研讨会论文集, 1978 年 11 月,第 133-139 页。

Cavano, J., and J. McCall, “A Framework for the Measurement of Software Quality,” Proceedings ACM Software Quality Assurance Workshop, November 1978, pp. 133–139.

[坐标测量机18a]

[CMM18a]

能力成熟度模型集成 (CMMI),软件工程学院,2018 年,

可在 https://cmmiinstitute.com/cmmi 获取。

Capability Maturity Model Integration (CMMI), Software Engineering Institute, 2018,

available at https://cmmiinstitute.com/cmmi.

[坐标测量机18b]

[CMM18b]

人员能力成熟度模型集成 (People CMM),软件工程学院,2018 年,可在 https://cmmiinstitute.com/cmmi/pm 获取。

People Capability Maturity Model Integration (People CMM), Software Engineering Institute, 2018, available at https://cmmiinstitute.com/cmmi/pm.

[查89]

[Cha89]

Charette, R.,软件工程风险分析和管理, McGraw-Hill/Intertext,1989 年。

Charette, R., Software Engineering Risk Analysis and Management, McGraw-Hill/Intertext, 1989.

[查92]

[Cha92]

Charette, R.,“在智能河流上搭建桥梁”,《美国程序员》,卷。5、没有。7,1992 年 9 月,第 2-9 页。

Charette, R., “Building Bridges over Intelligent Rivers,” American Programmer, vol. 5, no. 7, September 1992, pp. 2–9.

[查93]

[Cha93]

de Champeaux, D.、D. Lea 和 P. Faure,《面向对象系统开发》, Addison-Wesley,1993 年。

de Champeaux, D., D. Lea, and P. Faure, Object-Oriented System Development, Addison-Wesley, 1993.

[Chi94]

[Chi94]

Chidamber, S. 和 C. Kemerer,“面向对象设计的度量套件”,IEEE 软件工程汇刊,卷。SE-20,没有。6,1994 年 6 月,第 476-493 页。

Chidamber, S., and C. Kemerer, “A Metrics Suite for Object-Oriented Design,” IEEE Transactions on Software Engineering, vol. SE-20, no. 6, June 1994, pp. 476–493.

[Cho16]

[Cho16]

Choma, J. 等人,“大型 Web 应用程序用户界面设计的交互模式”,第11 届拉丁美洲编程模式语言会议 (SugarLoafPLoP '16), 2016 年,The Hillside Group,第 8 篇,第 11 页。

Choma, J., et al., “Interaction Patterns for User Interface Design of Large Web Applications,” Proceedings 11th Latin-American Conference on Pattern Languages of Programming (SugarLoafPLoP ’16), 2016, The Hillside Group, Article 8, 11 pages.

[第 17 章]

[Chr17]

Christensen, E.,“如何创建客户旅程地图”,2017 年,可访问 https://www.lucidchart.com/blog/how-to-build-customer-journey-maps。

Christensen, E., “How to Create a Customer Journey Map,” 2017, available at https://www.lucidchart.com/blog/how-to-build-customer-journey-maps.

[楚09]

[Chu09]

Chung, L. 和 J. Leite,“论软件工程中的非功能性需求”,AT Borgida 等人。(编辑),概念建模:基础和应用, Springer-Verlag,2009 年。

Chung, L., and J. Leite, “On Non-Functional Requirements in Software Engineering,” in A. T. Borgida et al. (eds.), Conceptual Modeling: Foundations and Applications, Springer-Verlag, 2009.

[烟07]

[Cig07]

Cigital, Inc.,“案例研究:尽早发现缺陷可节省大量成本”,2007 年。

Cigital, Inc., “Case Study: Finding Defects Earlier Yields Enormous Savings,” 2007.

[分类05]

[Cla05]

Clark, S. 和 E. Baniasaad,面向方面的分析和设计, Addison-Wesley,2005 年。

Clark, S., and E. Baniasaad, Aspect-Oriented Analysis and Design, Addison-Wesley, 2005.

[克莱03]

[Cle03]

Clements, P.、R. Kazman 和 M. Klein,评估软件架构:方法和案例研究, Addison-Wesley,2003 年。

Clements, P., R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley, 2003.

[克莱10]

[Cle10]

Clements, P. 和 L. Bass,“业务目标观点”,IEEE Software,卷。27、没有。6,2010 年 11 月至 12 月,第 38-45 页。

Clements, P., and L. Bass, “The Business Goals Viewpoint,” IEEE Software, vol. 27, no. 6, November–December 2010, pp. 38–45.

[三坐标测量机07]

[CMM07]

能力成熟度模型集成 (CMMI),软件工程学院,2007 年,可访问 www.sei.cmu.edu/cmmi/。

Capability Maturity Model Integration (CMMI), Software Engineering Institute, 2007, available at www.sei.cmu.edu/cmmi/.

[Coa91]

[Coa91]

Coad, P. 和 E. Yourdon,《面向对象分析》,第二版,Prentice Hall,1991 年。

Coad, P., and E. Yourdon, Object-Oriented Analysis, 2nd ed., Prentice Hall, 1991.

[可可01a]

[Coc01a]

第643页Cockburn, A. 和 J. Highsmith,“敏捷软件开发:人的因素”,IEEE 计算机,卷。34、没有。11,2001 年 11 月,第 131-133 页。

Page 643Cockburn, A., and J. Highsmith, “Agile Software Development: The People Factor,” IEEE Computer, vol. 34, no. 11, November 2001, pp. 131–133.

[Coc01b]

[Coc01b]

Cockburn, A.,《编写有效的用例》, Addison-Wesley,2001 年。

Cockburn, A., Writing Effective Use-Cases, Addison-Wesley, 2001.

[可可02]

[Coc02]

Cockburn, A.,敏捷软件开发, Addison-Wesley,2002 年。

Cockburn, A., Agile Software Development, Addison-Wesley, 2002.

[科05]

[Coh05]

Cohn, M.,“使用用例点进行估算”,方法与工具, 2005 年秋季,可从 http://www.mountaingoatsoftware.com/articles/estimating-with-use-case-points 获取。

Cohn, M., “Estimating with Use Case Points,” Methods & Tools, Fall 2005, available at http://www.mountaingoatsoftware.com/articles/estimating-with-use-case-points.

[Con02]

[Con02]

Conradi, R. 和 A. Fuggetta,“改进软件流程改进”,IEEE Software, 2002 年 7 月至 8 月,第 2-9 页,可从 http://citeseer.ist.psu.edu/conradi0​​2improving.html 获取。

Conradi, R., and A. Fuggetta, “Improving Software Process Improvement,” IEEE Software, July–August 2002, pp. 2–9, available at http://citeseer.ist.psu.edu/conradi02improving.html.

[Con10]

[Con10]

Conway, D.,《数据科学维恩图》, 2010 年,可访问 http://drewconway.com/zia/2013/3/26/the-data-science-venn-diagram。

Conway, D., The Data Science Venn Diagram, 2010, available at http://drewconway.com/zia/2013/3/26/the-data-science-venn-diagram.

[Con95]

[Con95]

Constantine, L.,“用户想要什么?软件工程可用性”,Windows 技术期刊, 1995 年 12 月,可从 http://www.wytsg.org:88/reslib/400/180/110/020/030/050/060/L000000000240585.pdf 获取

Constantine, L., “What DO Users Want? Engineering Usability in Software,” Windows Tech Journal, December 1995, available at http://www.wytsg.org:88/reslib/400/180/110/020/030/

050/060/L000000000240585.pdf.

[Cro79]

[Cro79]

Crosby, P.,《质量是免费的》, McGraw-Hill,1979 年。

Crosby, P., Quality Is Free, McGraw-Hill, 1979.

[克罗07]

[Cro07]

Cross, M.,Web 应用程序安全开发人员指南, Syngress,2007 年。

Cross, M., Developer’s Guide to Web Application Security, Syngress, 2007.

[当前09]

[Cur09]

Curtis, B. 和 W. Heflley,《人员 CMM:人力资本管理框架》,第 2 版,Addison-Wesley,2009 年。

Curtis, B., and W. Heflley, The People CMM: A Framework for Human Capital Management, 2nd ed., Addison-Wesley, 2009.

[当前90]

[Cur90]

Curtis, B. 和 D. Walz,“大规模编程心理学:团队和组织行为”,编程心理学,学术出版社,1990 年。

Curtis, B., and D. Walz, “The Psychology of Programming in the Large: Team and Organizational Behavior,” Psychology of Programming, Academic Press, 1990.

[DAC03]

[DAC03]

“基于模型的软件测试概述”,软件数据和分析中心,CR/TA 12,2003 年 6 月。

“An Overview of Model-Based Testing for Software,” Data and Analysis Center for Software, CR/TA 12, June 2003.

[达72]

[Dah72]

Dahl, O.、E. Dijkstra 和 C. Hoare,结构化编程,学术出版社,1972 年。

Dahl, O., E. Dijkstra, and C. Hoare, Structured Programming, Academic Press, 1972.

[达克14]

[Dak14]

Daka, E. 和 G. Fraser,“单元测试实践和问题调查”,2014 年 IEEE

第 25 届软件可靠性工程国际研讨会,
那不勒斯,2014 年,

第 201-211 页。

Daka, E., and G. Fraser, “A Survey on Unit Testing Practices and Problems,” 2014 IEEE

25th International Symposium on Software Reliability Engineering,
Naples, 2014,

pp. 201–211.

[大坝17]

[Dam17]

Dam, R. 和 T. Siang,“测试你的原型:如何收集反馈并最大化学习”,2017 年 10 月,可访问 https://www.interaction-design.org/literature/article/test-your-prototypes -如何收集反馈和最大化学习。

Dam, R., and T. Siang, “Test Your Prototype: How to Gather Feedback and Maximize Learning,” October 2017, available at https://www.interaction-design.org/literature/article/test-your-prototypes-how-to-gather-feedback-and-maximise-learning.

[达尔01]

[Dar01]

Dart, S.,配置管理系统中的功能频谱,软件工程学院,2001 年,可在 www.sei.cmu.edu/legacy/scm/tech_rep/TR11_90/TOC_TR11_90.html 上获取。

Dart, S., Spectrum of Functionality in Configuration Management Systems, Software Engineering Institute, 2001, available at www.sei.cmu.edu/legacy/scm/tech_rep/TR11_90/TOC_TR11_90.html.

[达尔91]

[Dar91]

Dart, S.,“配置管理系统中的概念”,第三届软件配置管理国际研讨会论文集, ACM SIGSOFT,1991 年,网址为 https://dl.acm.org/itation.cfm?id=111063。

Dart, S., “Concepts in Configuration Management Systems,” Proceedings Third International Workshop on Software Configuration Management, ACM SIGSOFT, 1991, available at https://dl.acm.org/citation.cfm?id=111063.

[达斯15]

[Das15]

Dasanayake, S. 等人,“软件架构决策实践和挑战:工业案例研究”,第 24 届澳大利亚软件工程会议论文集,澳大利亚,2015 年。第 88-97 页。

Dasanayake, S., et al., “Software Architecture Decision-Making Practices and Challenges: An Industrial Case Study,” Proceedings of the 24th Australasian Software Engineering Conference, SA, Australia, 2015. pp. 88–97.

[达夫93]

[Dav93]

Davis, A. 等人,“识别和测量软件需求规范中的质量”,《软件需求规范》论文集。第一届国际软件度量研讨会, IEEE,马里兰州巴尔的摩,1993 年 5 月,第 141-152 页。

Davis, A., et al., “Identifying and Measuring Quality in a Software Requirements Specification,” Proceedings of the. First International Software Metrics Symposium, IEEE, Baltimore, MD, May 1993, pp. 141–152.

[达夫95a]

[Dav95a]

Davis, M.,“过程和产品:二分法或二元性”,软件工程笔记, ACM Press,卷。20、没有。2,1995 年 4 月,第 17-18 页。

Davis, M., “Process and Product: Dichotomy or Duality,” Software Engineering Notes, ACM Press, vol. 20, no. 2, April 1995, pp. 17–18.

[达夫95b]

[Dav95b]

Davis, A.,201 软件开发原理, McGraw-Hill,1995。

Davis, A., 201 Principles of Software Development, McGraw-Hill, 1995.

[第99天]

[Day99]

Dayani-Fard, H. 等人,“遗留软件系统:问题、进展和挑战”,IBM 技术报告:TR-74.165-k,1999 年 4 月。

Dayani-Fard, H., et al., “Legacy Software Systems: Issues, Progress, and Challenges,” IBM Technical Report: TR-74.165-k, April 1999.

[Dem86]

[Dem86]

Deming, W.,《走出危机》,麻省理工学院出版社,1986 年。

Deming, W., Out of the Crisis, MIT Press, 1986.

[DeM95]

[DeM95]

DeMarco, T.,为什么软件成本如此之高?多塞特宫,1995。

DeMarco, T., Why Does Software Cost So Much? Dorset House, 1995.

[DeM98]

[DeM98]

DeMarco, T. 和 T. Lister,Peopleware,第 2 版,Dorset House,1998 年。

DeMarco, T., and T. Lister, Peopleware, 2nd ed., Dorset House, 1998.

[书房73]

[Den73]

Dennis, J.,“模块化”,《软件工程高级课程》, FL Bauer(编辑),Springer-Verlag,1973 年,第 128-182 页。

Dennis, J., “Modularity,” in Advanced Course on Software Engineering, F. L. Bauer (ed.), Springer-Verlag, 1973, pp. 128–182.

[设计08]

[Des08]

de Sáa, M. 和 L. Carriocço,“移动应用程序早期设计的经验教训”,第十届移动服务和设备人机交互国际会议记录, 2008 年,第 127-136 页。

de Sáa, M., and L. Carriocço, “Lessons from Early Stages Design of Mobile Applications,” Proceedings of 10th International Conference on Human Computer Human with Mobile Services and Devices, 2008, pp. 127–136.

[设计09]

[Des09]

de Souza, C.、H. Sharp、G. Venolia 和 L. Cheng,“客座编辑简介:软件工程的合作和人性化方面”,IEEE Software,卷。26、没有。6,2009 年,

第 17-19 页。

de Souza, C., H. Sharp, G. Venolia, and L. Cheng, “Guest Editors’ Introduction: Cooperative and Human Aspects of Software Engineering,” IEEE Software, vol. 26, no. 6, 2009,

pp. 17–19.

[检测11]

[Det11]

第644页Deterding, S. 等人,“从游戏设计元素到游戏性:定义游戏化”,2011 年年会记录计算系统中的人为因素扩展摘要 — CHI EA '11, 2011 年,第 11 页。2425.

Page 644Deterding, S., et al., “From Game Design Elements to Gamefulness: Defining Gamification,” Proceedings of the 2011 Annual Conference Extended Abstracts on Human Factors in Computing Systems—CHI EA ’11, 2011, p. 2425.

[直径14]

[Dia14]

Díaz-Bossini, J. 和 L. Moreno,“老年人移动界面的可访问性”,Procedia 计算机科学,卷。2014 年 27 日,第 57-66 页。

Díaz-Bossini, J., and L. Moreno, “Accessibility to Mobile Interfaces for Older People,” Procedia Computer Science, vol. 27, 2014, pp. 57–66.

[迪吉65]

[Dij65]

Dijkstra, E.,“编程被视为人类活动”,1965 年 IFIP 大会论文集,北荷兰出版公司,1965 年。

Dijkstra, E., “Programming Considered as a Human Activity,” Proceedings 1965 IFIP Congress, North-Holland Publishing Co., 1965.

[迪吉72]

[Dij72]

Dijkstra, E.,“谦虚的程序员”,1972 年 ACM 图灵奖演讲,CACM,卷。15、没有。10,1972 年 10 月,第 859-866 页。

Dijkstra, E., “The Humble Programmer,” 1972 ACM Turing Award Lecture, CACM, vol. 15, no. 10, October 1972, pp. 859–866.

[迪吉76a]

[Dij76a]

Dijkstra, E., 《软件工程、概念和技术》中的“结构化编程” ,J. Buxton 等人。(编),范·诺斯特兰德-莱因霍尔德,1976 年。

Dijkstra, E., “Structured Programming,” in Software Engineering, Concepts and Techniques, J. Buxton et al. (eds.), Van Nostrand-Reinhold, 1976.

[迪吉76b]

[Dij76b]

Dijkstra, E.,编程学科, Prentice Hall,1976 年。

Dijkstra, E., A Discipline of Programming, Prentice Hall, 1976.

[迪吉82]

[Dij82]

Dijksta, E.,“论科学思想的作用”,《计算著作精选:个人观点》, Springer-Verlag,1982 年。

Dijksta, E., “On the Role of Scientific Thought,” in Selected Writings on Computing: A Personal Perspective, Springer-Verlag, 1982.

[丁16]

[Din16]

Dingsøyr, T. 和 C. Lassenius,“敏捷软件开发中的新兴主题:持续价值交付特别部分简介”,信息和软件技术,卷。77,2016 年,第 56-60 页。

Dingsøyr, T., and C. Lassenius, “Emerging Themes in Agile Software Development: Introduction to the Special Section on Continuous Value Delivery,” Information and Software Technology, vol. 77, 2016, pp. 56–60.

[迪克斯99]

[Dix99]

Dix, A.,“Web 用户界面设计”,数据系统用户界面会议论文集, 1999 年 9 月,可在 www.comp.lancs.ac.uk/computing/users/dixa/topics/webarch/ 上获取。

Dix, A., “Design of User Interfaces for the Web,” Proceedings User Interfaces to Data Systems Conference, September 1999, available at www.comp.lancs.ac.uk/computing/users/dixa/topics/webarch/.

[唐99]

[Don99]

Donahue, G.、S. Weinschenck 和 J. Nowicki,“可用性是好生意”,Compuware Corp.,1999 年 7 月,可在 www.compuware.com 上获取。

Donahue, G., S. Weinschenck, and J. Nowicki, “Usability Is Good Business,” Compuware Corp., July 1999, available at www.compuware.com.

[杜克01]

[Duc01]

Ducatel, K. 等人,《2010 年环境智能情景》,ISTAG-欧洲委员会,2001 年,参见 https://www.researchgate.net/publication/262007900_Scenarios_for_ambient_intelligence_in_2010

Ducatel, K., et al., Scenarios for Ambient Intelligence in 2010, ISTAG-European Commission, 2001, available at https://www.researchgate.net/publication/262007900_Scenarios_for_

ambient_intelligence_in_2010.

[邓82]

[Dun82]

Dunn, R. 和 R. Ullman,《计算机软件质量保证》, McGraw-Hill,1982 年。

Dunn, R., and R. Ullman, Quality Assurance for Computer Software, McGraw-Hill, 1982.

[杜特15]

[Dut15]

Dutra, E. 和 G. Santos,“软件流程改进实施风险:基于巴西软件开发成熟度模型实施的定性研究”,《以产品为中心的软件流程改进》,PROFES 2015 计算机科学讲义 P. Abrahamsson等人。(编辑),卷。9459,施普林格,2015。

Dutra, E., and G. Santos, “Software Process Improvement Implementation Risks: A Qualitative Study Based on Software Development Maturity Models Implementations in Brazil,” in Product-Focused Software Process Improvement, PROFES 2015 Lecture Notes in Computer Science, P. Abrahamsson et al. (eds.), vol. 9459, Springer, 2015.

[DXL18]

[DXL18]

DX Lab Design Sprint,“使用 Google 的方法使您的 UX 设计流程变得敏捷”,请访问 https://www.interaction-design.org/literature/article/make-your-ux-design-process-agile-using-google -s-方法论,2018。

DX Lab Design Sprint, “Make Your UX Design Process Agile Using Google’s Methodology,” available at https://www.interaction-design.org/literature/article/make-your-ux-design-process-agile-using-google-s-methodology, 2018.

[染料15]

[Dye15]

Dyer, R. 等人,“Boa:超大规模软件存储库和源代码挖掘”,ACM Transactions on Software Engineering Methodology,卷。25、没有。1,第 7 条,2015 年 12 月。

Dyer, R., et al., “Boa: Ultra-Large-Scale Software Repository and Source-Code Mining,” ACM Transactions on Software Engineering Methodology, vol. 25, no. 1, Article 7, December 2015.

[埃贝14]

[Ebe14]

Ebert, C.“软件产品管理”,IEEE 软件,卷。31、没有。3,2014 年 5 月至 6 月,第 21-24 页。

Ebert, C. “Software Product Management,” IEEE Software, vol. 31, no. 3, May–June 2014, pp. 21–24.

[Edg95]

[Edg95]

Edgemon, J.,“正确的东西:选择项目经理时如何识别它”,应用程序开发趋势,卷。2、没有。5,1995 年 5 月,第 37-42 页。

Edgemon, J., “Right Stuff: How to Recognize It When Selecting a Project Manager,” Application Development Trends, vol. 2, no. 5, May 1995, pp. 37–42.

[Eis01]

[Eis01]

Eisenstein, J. 等人,“将基于模型的技术应用于移动计算机 UI 的开发”,智能用户界面论文集, 2001 年 1 月。

Eisenstein, J., et al., “Applying Model-Based Techniques to the Development of UIs for Mobile Computers,” Proceedings of Intelligent User Interfaces, January 2001.

[Eji91]

[Eji91]

Ejiogu, L.,《软件工程与形式度量》, QED Publishing,1991。

Ejiogu, L., Software Engineering with Formal Metrics, QED Publishing, 1991.

[Elb16]

[Elb16]

Elbanna, A. 和 S. Sarker,“敏捷开发的风险:向采用者学习”,IEEE Software,卷。33、没有。5,2016 年 9 月至 10 月,第 72-79 页。

Elbanna, A., and S. Sarker, “The Risks of Agile Development: Learning from Adopters,” IEEE Software, vol. 33, no. 5, September–October 2016, pp. 72–79.

[时代09]

[Era09]

Erasmus, H.,“超级专业人士的七个特质”,IEEE 软件,卷。26、没有。4,2009

年 7 月至 8 月,第 4-6 页。

Erasmus, H., “The Seven Traits of Superprofessionals,” IEEE Software, vol. 26, no. 4,

July–August 2009, pp. 4–6.

[Erd10]

[Erd10]

Erdogmus, H.,“似曾相识:软件工程思想的生命”,IEEE Software,卷。27、没有。1,2010 年 1 月至 2 月,第 2-3 页。

Erdogmus, H., “Déjà vu: The Life of Software Engineering Ideas,” IEEE Software, vol. 27, no. 1, January–February 2010, pp. 2–3.

[埃里15]

[Eri15]

Ericson, C.,系统安全危害分析技术,第二版,Wiley,2015 年。

Ericson, C., Hazard Analysis Techniques for System Safety, 2nd ed., Wiley, 2015.

[前夕09]

[Eve09]

Everett, G. 和 B. Meyer,“Point/Counterpoint”,IEEE 软件,卷。26、没有。4,2009 年 7 月至 8 月,第 62-65 页。

Everett, G., and B. Meyer, “Point/Counterpoint,” IEEE Software, vol. 26, no. 4, July–August 2009, pp. 62–65.

[Fag86]

[Fag86]

Fagan, M.,“软件检查的进展”,IEEE 软件工程汇刊,卷。12、没有。6、1986 年 7 月。

Fagan, M., “Advances in Software Inspections,” IEEE Transactions on Software Engineering, vol. 12, no. 6, July 1986.

[辉17]

[Fai17]

Fairley, R. 和 MJ Willshire,“现在比以后更好:管理系统开发中的技术债务”,计算机,卷。50,没有。5,2017 年 5 月,第 80-87 页。

Fairley, R., and M. J. Willshire, “Better Now Than Later: Managing Technical Debt in Systems Development,” Computer, vol. 50, no. 5, May 2017, pp. 80–87.

[Fal10]

[Fal10]

Falessi, D. 等人,“和平共存:敏捷开发人员对软件架构的看法”,IEEE Software,卷。27、没有。3,2010 年 3 月至 4 月,第 23-25 页。

Falessi, D., et al., “Peaceful Coexistence: Agile Developer Perspectives on Software Architecture,” IEEE Software, vol. 27, no. 3, March–April 2010, pp. 23–25.

[菲尔07]

[Fel07]

第645页费勒,J.,等人。(编辑),自由和开源软件的观点,麻省理工学院出版社,2007 年。

Page 645Feller, J., et al. (eds.), Perspectives on Free and Open Source Software, The MIT Press, 2007.

[菲尔18]

[Fel18]

Feldt, R. 等人,“在软件工程中应用人工智能的方法”,第六届软件工程中实现人工智能协同作用国际研讨会 (RAISE '18) 论文集。ACM,纽约州,2018 年,第 35-41 页。

Feldt, R., et al., “Ways of Applying Artificial Intelligence in Software Engineering,” In Proceedings of the 6th International Workshop on Realizing Artificial Intelligence Synergies in Software Engineering (RAISE ’18). ACM, New York, NY, 2018, pp. 35–41.

[菲尔89]

[Fel89]

Felican, L. 和 G. Zalateu,“验证 Halstead 的 Pascal 程序理论”,IEEE 软件工程汇刊,卷。SE-15,没有。2,1989 年 12 月,第 1630-1632 页。

Felican, L., and G. Zalateu, “Validating Halstead’s Theory for Pascal Programs,” IEEE Transactions on Software Engineering, vol. SE-15, no. 2, December 1989, pp. 1630–1632.

[芬91]

[Fen91]

Fenton, N.,软件指标, Chapman 和 Hall,1991 年。

Fenton, N., Software Metrics, Chapman and Hall, 1991.

[芬94]

[Fen94]

Fenton, N.,“软件测量:必要的科学基础”,IEEE 软件工程汇刊,卷。SE-20,没有。3,1994 年 3 月,第 199-206 页。

Fenton, N., “Software Measurement: A Necessary Scientific Basis,” IEEE Transactions on Software Engineering, vol. SE-20, no. 3, March 1994, pp. 199–206.

[F14]

[Fer14]

Ferrucci F.、M. Harman 和 F. Sarro,“基于搜索的软件项目管理”,《变化世界中的软件项目管理》, G. Ruhe 和 C. Wohlin(编辑),

Springer,2014 年。

Ferrucci F., M. Harman, and F. Sarro, “Search-Based Software Project Management,” in Software Project Management in a Changing World, G. Ruhe and C. Wohlin (eds.),

Springer, 2014.

[冷杉13]

[Fir13]

Firesmith, D.,软件密集型系统的安全和安全要求,奥尔巴赫,2013 年。

Firesmith, D., Security and Safety Requirements for Software-Intensive Systems, Auerbach, 2013.

[福00]

[Fow00]

Fowler, M. 等人,《重构:改进现有代码的设计》, Addison-Wesley,2000 年。

Fowler, M., et al., Refactoring: Improving the Design of Existing Code, Addison-Wesley, 2000.

[福01]

[Fow01]

Fowler, M. 和 J. Highsmith,“敏捷宣言”,软件开发 杂志, 2001 年 8 月。

Fowler, M., and J. Highsmith, “The Agile Manifesto,” Software Development Magazine, August 2001.

[福02]

[Fow02]

Fowler, M.,“新方法论”,参见 www.martinfowler.com/articles/newMethodology.html#N8B,2002

年 6 月。

Fowler, M., “The New Methodology,” available at www.martinfowler.com/articles/

newMethodology.html#N8B, June 2002.

[福03]

[Fow03]

Fowler, M. 等人,《企业应用程序架构模式》, Addison-Wesley,2003 年。

Fowler, M., et al., Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.

[福04]

[Fow04]

Fowler, M.,《UML Distilled》,第 3 版,Addison-Wesley,2004 年。

Fowler, M., UML Distilled, 3rd ed., Addison-Wesley, 2004.

[Fow16]

[Fow16]

Fowler, M. 和 Sutherland, J.,《Scrum 指南》, 2016 年,可从 http://www.scrumguides.org/ 获取。

Fowler, M., and Sutherland, J., The Scrum Guide, 2016, available at, http://www.scrumguides.org/.

[Fow97]

[Fow97]

Fowler, M.,分析模式:可重用对象模型, Addison-Wesley,1997 年。

Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997.

[法93]

[Fra93]

Frankl, P. 和 S. Weiss,“分支测试和数据流有效性的实验比较”,IEEE 软件工程汇刊,卷。19、没有。8,1993 年 8 月,第 770-787 页。

Frankl, P., and S. Weiss, “An Experimental Comparison of the Effectiveness of Branch Testing and Data Flow,” IEEE Transactions on Software Engineering, vol. 19, no. 8, August 1993, pp. 770–787.

[弗90]

[Fre90]

Freedman, D. 和 G. Weinberg,演练、检查和技术审查手册,第 3 版,Dorset House,1990 年。

Freedman, D., and G. Weinberg, Handbook of Walkthroughs, Inspections and Technical Reviews, 3rd ed., Dorset House, 1990.

[10 周五]

[Fri10]

Fricker, S.,“与实施提案握手:协商需求理解”,IEEE Software,卷。27、没有。2,2010 年 3 月至 4 月,第 72-80 页。

Fricker, S., “Handshaking with Implementation Proposals: Negotiating Requirements Understanding,” IEEE Software, vol. 27, no. 2, March–April 2010, pp. 72–80.

[福格14]

[Fug14]

Fuggetta, A. 和 E. Di Nitto,“软件流程”,《软件工程未来论文集》(FOSE 2014), ACM,纽约,纽约,2014 年,第 1-12 页。

Fuggetta, A., and E. Di Nitto, “Software Process,” in Proceedings of the on Future of Software Engineering (FOSE 2014), ACM, New York, NY, 2014, pp. 1–12.

[插嘴04]

[Gag04]

Gage, D. 和 J. McCormick,“我们没有做错任何事”,Baseline 杂志, 2004 年 3 月 4 日,可访问 http://www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing -错误的。

Gage, D., and J. McCormick, “We Did Nothing Wrong,” Baseline Magazine, March 4, 2004, available at http://www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing-Wrong.

[盖95]

[Gai95]

Gaines, B.,“信息科学建模和预测”,技术报告,卡尔加里大学,1995 年 9 月,下载地址:https://www.lri.fr/~mbl/ENS/FundHCI/2017/papers/Gaines-BRETAM99 .pdf。

Gaines, B., “Modeling and Forecasting the Information Sciences,” Technical Report, University of Calgary, September 1995, downloadable at https://www.lri.fr/~mbl/ENS/FundHCI/2017/papers/Gaines-BRETAM99.pdf.

[半乳糖16]

[Gal16]

Galster, M. 等人,“软件设计中的可变性和复杂性”,ACM SIGSOFT 软件工程笔记,卷。41、没有。6,2016 年 11 月,第 27-30 页。

Galster, M., et al., “Variability and Complexity in Software Design,” ACM SIGSOFT Software Engineering Notes, vol. 41, no. 6, November 2016, pp. 27–30.

[半乳糖17]

[Gal17]

Galster, M. 等人,“软件设计中的可变性和复杂性:迈向研究议程”,SIGSOFT 软件工程笔记,卷。41号 6,2017 年 1 月,第 27-30 页。

Galster, M., et al., “Variability and Complexity in Software Design: Towards a Research Agenda,” SIGSOFT Software Engineering Notes, vol. 41 no. 6, January 2017, pp. 27–30.

[加姆95]

[Gam95]

Gamma, E. 等人,设计模式:可重用面向对象软件的元素, Addison-Wesley,1995 年。

Gamma, E., et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

[加尔08]

[Gar08]

GartnerGroup,“理解技术成熟度曲线”,2008 年,可访问 https://www.gartner.com/en/documents/3887767。

GartnerGroup, “Understanding Hype Cycles,” 2008, available at https://www.gartner.com/en/documents/3887767.

[加尔09a]

[Gar09a]

Garlan, D. 等人,“架构不匹配:重用方式仍然如此困难”,IEEE 软件,卷。26、没有。4,2009 年 7 月至 8 月,第 66-69 页。

Garlan, D., et al., “Architectural Mismatch: Way Reuse Is Still So Hard,” IEEE Software, vol. 26, no. 4, July–August 2009, pp. 66–69.

[加尔10a]

[Gar10a]

Garcia-Crespo, A. 等人,“管理全球软件开发团队中的硬决策的定性研究”,《管理信息系统杂志》,卷。27、没有。3,2010 年 6 月,第 247-252 页。

Garcia-Crespo, A., et al., “A Qualitative Study of Hard Decision Making in Managing Global Software Development Teams,” Journal of Management Information Systems, vol. 27, no. 3, June 2010, pp. 247–252.

[加尔10b]

[Gar10b]

Garrett, JJ,《用户体验的要素:以用户为中心的网络设计及其他》,第二版,New Riders Publishing,2010 年。

Garrett, J. J., The Elements of User Experience: User-Centered Design for the Web and Beyond, 2nd ed., New Riders Publishing, 2010.

[加尔84]

[Gar84]

Garvin, D.,“‘产品质量’的真正含义是什么?” 《斯隆管理评论》, 1984 年秋季,第 25-45 页。

Garvin, D., “What Does ‘Product Quality’ Really Mean?” Sloan Management Review, Fall 1984, pp. 25–45.

[加尔95]

[Gar95]

Garlan, D. 和 M. Shaw,“软件架构简介”,软件工程和知识工程进展 ,卷。I、V. Ambriola 和 G. Tortora(编辑),世界科学出版公司,1995 年。

Garlan, D., and M. Shaw, “An Introduction to Software Architecture,” Advances in Software Engineering and Knowledge Engineering, vol. I, V. Ambriola and G. Tortora (eds.), World Scientific Publishing Company, 1995.

[气体17]

[Gas17]

第646页Gasparic, M. 等人,“IDE 命令建议的 GUI 设计”,第 22 届智能用户界面国际会议 (IUI '17) 论文集, 2017 年,ACM,纽约州,第 595-599 页。

Page 646Gasparic, M., et al., “GUI Design for IDE Command Recommendations,” Proceedings of the 22nd International Conference on Intelligent User Interfaces (IUI ’17), 2017, ACM, New York, NY, pp. 595–599.

[高89]

[Gau89]

Gause, D. 和 G. Weinberg,《探索要求:设计之前的质量》, Dorset House,1989 年。

Gause, D., and G. Weinberg, Exploring Requirements: Quality Before Design, Dorset House, 1989.

[17岁]

[Ger17]

Géron, A.,使用 Scikit-Learn 和 TensorFlow 进行机器学习实践, O'Reilly Media,2017 年。

Géron, A., Hands-On Machine Learning with Scikit-Learn and TensorFlow, O’Reilly Media, 2017.

[盖伊01]

[Gey01]

Geyer-Schulz, A. 和 M. Hahsler,“具有分析模式的软件工程”,技术报告 01/2001,Institut für Informationsverarbeitung undwirtschaft,Wirschaftsuniversität Wien,2001 年 11 月,可在 https://www.researchgate.net/publication 获取/250241449_Software_Engineering_with_Analysis_Patterns

Geyer-Schulz, A., and M. Hahsler, “Software Engineering with Analysis Patterns,” Technical Report 01/2001, Institut für Informationsverarbeitung undwirtschaft, Wirschaftsuniversität Wien, November 2001, available at https://www.researchgate.net/publication/250241449_

Software_Engineering_with_Analysis_Patterns.

[加14]

[Gha14]

Ghazi, P.、AM Moreno 和 L. Peters,“寻找软件开发的圣杯”,IEEE Software,卷。31、没有。1,2014 年 1 月至 2 月,第 96 页。

Ghazi, P., A. M. Moreno, and L. Peters, “Looking for the Holy Grail of Software Development,” IEEE Software, vol. 31, no. 1, January–February 2014, pp. 96.

[吉尔06]

[Gil06]

Gillis, D.,“基于模式的设计”,tehan + lax 博客,2006 年 9 月 14 日。

Gillis, D., “Pattern-Based Design,” tehan + lax blog, September 14, 2006.

[吉尔88]

[Gil88]

Gilb, T.,软件项目管理原理, Addison-Wesley,1988。

Gilb, T., Principles of Software Project Management, Addison-Wesley, 1988.

[吉尔95]

[Gil95]

Gilb, T.,“我们在当前测试文化中未能做到的事情”,测试技术时事通讯(在线版,ttn@soft.com),软件研究,1995 年 1 月。

Gilb, T., “What We Fail to Do in Our Current Testing Culture,” Testing Techniques Newsletter (online edition, ttn@soft.com), Software Research, January 1995.

[格拉02]

[Gla02]

Gladwell, M.,《引爆点》,后湾图书公司,2002 年。

Gladwell, M., The Tipping Point, Back Bay Books, 2002.

[格拉98]

[Gla98]

Glass, R.,“直观地定义质量”,IEEE 软件, 1998 年 5 月至 6 月,第 103-104 页,107。

Glass, R., “Defining Quality Intuitively,” IEEE Software, May–June 1998, pp. 103–104, 107.

[Gli07]

[Gli07]

Glinz, M. 和 R. Wieringa,“需求工程的利益相关者”,IEEE Software,卷。24、没有。2,2007 年 3 月至 4 月,第 18-20 页。

Glinz, M., and R. Wieringa, “Stakeholders in Requirements Engineering,” IEEE Software, vol. 24, no. 2, March–April 2007, pp. 18–20.

[谷氨酸94]

[Glu94]

Gluch, D.,“描述软件开发风险的构造”,CMU/SEI-94-TR-14,软件工程研究所,1994 年。

Gluch, D., “A Construct for Describing Software Development Risks,” CMU/SEI-94-TR-14, Software Engineering Institute, 1994.

[Gna99]

[Gna99]

Gnaho, C. 和 F. Larcher,“复杂和可定制 Web 工程的以用户为中心的方法”,第一届 ICSE Web 工程研讨会论文集, ACM,洛杉矶,1999 年 5 月。

Gnaho, C., and F. Larcher, “A User-Centered Methodology for Complex and Customizable Web Engineering,” Proceedings of the First ICSE Workshop on Web Engineering, ACM, Los Angeles, May 1999.

[果阿14]

[Goa14]

高 J. 等人,“移动应用程序测试:教程”,计算机,卷。47、没有。2,2014 年,第 46-55 页。

Gao, J., et al., “Mobile Application Testing: A Tutorial,” Computer, vol. 47, no. 2, 2014, pp. 46–55.

[贡04]

[Gon04]

Gonzales, R.,“需求工程”,桑迪亚国家实验室,2004 年,幻灯片

演示。

Gonzales, R., “Requirements Engineering,” Sandia National Laboratories, 2004, a slide

presentation.

[贡17]

[Gon17]

Gonzalez, D. 等人,“关于解决可维护性属性的测试模式的使用的大规模研究:易于修改、诊断和理解的模式”,第 14 届国际采矿软件存储库会议 (MSR)论文集'17)。IEEE 出版社,新泽西州皮斯卡塔韦,2017 年,第 391–401 页。

Gonzalez, D., et al., “A Large-Scale Study on the Usage of Testing Patterns That Address Maintainability Attributes: Patterns for Ease of Modification, Diagnoses, and Comprehension,” Proceedings of the 14th International Conference on Mining Software Repositories (MSR ’17). IEEE Press, Piscataway, NJ, 2017, pp. 391–401.

[咕18]

[Goo18]

Google,设计冲刺套件,2018 年,可访问 https://designsprintkit.withgoogle.com/。

Google, Design Sprint Kit, 2018, available at https://designsprintkit.withgoogle.com/.

[戈尔06]

[Gor06]

Gorton, I.,基本软件架构, Springer,2006 年。

Gorton, I., Essential Software Architecture, Springer, 2006.

[得到11]

[Got11]

Gotel, O. 和 S. Morris,“需求跟踪”,IEEE 软件,卷。28、没有。5,2011 年 9 月至 10 月,第 92-94 页。

Gotel, O., and S. Morris, “Requirements Tracery,” IEEE Software, vol. 28, no. 5, September–October 2011, pp. 92–94.

[得到18]

[Got18]

Gotterbarn, D. 等人,“专业思考:计算伦理兴趣的不断演变”,ACM Inroads,卷。9、不。2,2018 年 4 月,第 10-12 页。

Gotterbarn, D., et al., “Thinking Professionally: The Continual Evolution of Interest in Computing Ethics,” ACM Inroads, vol. 9, no. 2, April 2018, pp. 10–12.

[格拉18]

[Gra18]

Gray, C. 等人,“UX 设计的黑暗(模式)面”,2018 年 CHI 计算系统人因会议论文集 (CHI '18)。ACM,纽约州纽约市,论文 534,2018 年。

Gray, C., et al., “The Dark (Patterns) Side of UX Design,” Proceedings 2018 CHI Conference on Human Factors in Computing Systems (CHI ’18). ACM, New York, NY, Paper 534, 2018.

[格拉92]

[Gra92]

Grady, RG,项目管理和流程改进的实用软件指标, Prentice Hall,1992 年。

Grady, R. G., Practical Software Metrics for Project Management and Process Improvement, Prentice Hall, 1992.

[格鲁00]

[Gru00]

Gruia-Catalin, R. 等人,“移动性软件工程:路线图”,第 22 届软件工程未来国际会议论文集, 2000 年。

Gruia-Catalin, R., et al., “Software Engineering for Mobility: A Roadmap,” Proceedings of the 22nd International Conference on the Future of Software Engineering, 2000.

[古普15]

[Gup15]

Gupta, S. 和 V. Suma,“数据挖掘:软件工程人性化知识发现工具”,2015 年第二届电子与通信系统国际会议 (ICECS),哥印拜陀,2015 年,第 1289-1293 页。

Gupta, S., and V. Suma, “Data Mining: A Tool for Knowledge Discovery in Human Aspect of Software Engineering,” 2015 2nd International Conference on Electronics and Communication Systems (ICECS), Coimbatore, 2015, pp. 1289–1293.

[肠15]

[Gut15]

Gutiérrez, J.、M. Escalona 和 M. Mejías,“功能测试用例生成的模型驱动方法”,系统与软件杂志,卷。109,2015 年,第 214-228 页。

Gutiérrez, J., M. Escalona, and M. Mejías, “A Model-Driven Approach for Functional Test Case Generation,” Journal of Systems and Software, vol. 109, 2015, pp. 214–228.

[Hac98]

[Hac98]

Hackos, J. 和 J. Redish,界面设计的用户和任务分析, Wiley,1998。

Hackos, J., and J. Redish, User and Task Analysis for Interface Design, Wiley, 1998.

[哈尔77]

[Hal77]

Halstead, M.,《软件科学要素》,北荷兰,1977 年。

Halstead, M., Elements of Software Science, North-Holland, 1977.

[哈尔98]

[Hal98]

Hall, EM,管理风险:软件系统开发方法, Addison-Wesley,1998 年。

Hall, E. M., Managing Risk: Methods for Software Systems Development, Addison-Wesley, 1998.

[哈尔11]

[Har11]

Harris, N. 和 P. Avgeriou,“基于模式的架构评论”,IEEE 软件,卷。28、没有。6,2011 年 11 月至 12 月,第 66-71 页。

Harris, N., and P. Avgeriou, “Pattern-Based Architecture Reviews,” IEEE Software, vol. 28, no. 6, November–December 2011, pp. 66–71.

[哈尔12a]

[Har12a]

Hardy, T.,软件和系统安全, Authorhouse,2012 年。

Hardy, T., Software and System Safety, Authorhouse, 2012.

[哈尔12b]

[Har12b]

第647页Harman, M.,“人工智能在软件工程中的作用”,首届软件工程中实现人工智能协同作用国际研讨会 (RAISE '12) 论文集。IEEE 出版社,新泽西州皮斯卡塔韦,2012 年,第 1-6 页。

Page 647Harman, M., “The Role of Artificial Intelligence in Software Engineering,” Proceedings First International Workshop on Realizing AI Synergies in Software Engineering (RAISE ’12). IEEE Press, Piscataway, NJ, 2012, pp. 1–6.

[哈尔14]

[Har14]

Harman, M. 等人,“产品线工程中基于搜索的软件工程:未来工作的调查和方向”,第 18 届国际软件产品线会议论文集, SPL14,意大利佛罗伦萨,第 1 卷。1,2014 年 9 月,第 5-18 页。

Harman, M., et al., “Search Based Software Engineering for Product Line Engineering: A Survey and Directions for Future Work,” Proceedings 18th International Software Product Line Conference, SPL14, Florence, Italy, vol. 1, September 2014, pp. 5–18.

[哈尔98]

[Har98]

Harrison, R.、S. Counsell 和 R. Nithi,“面向对象软件指标 MOOD 集的评估”,IEEE 软件工程汇刊,卷。SE-24,没有。6,1998 年 6 月,第 491-496 页。

Harrison, R., S. Counsell, and R. Nithi, “An Evaluation of the MOOD Set of Object-Oriented Software Metrics,” IEEE Transactions on Software Engineering, vol. SE-24, no. 6, June 1998, pp. 491–496.

[嘻15]

[Hee15]

Heeager, L. 和 J. Rose,“优化维护操作的敏捷开发实践:九种启发法”,《经验软件工程杂志》,卷。20、没有。6,2015 年,第 1762–1784 页。

Heeager, L., and J. Rose, “Optimising Agile Development Practices for the Maintenance Operation: Nine Heuristics,” Journal of Empirical Software Engineering, vol. 20, no. 6, 2015, pp. 1762–1784.

[黑02]

[Hei02]

Heitmeyer, C.,“软件成本降低”,《软件工程百科全书》, JJ Marciniak(编辑),第 2 卷,John Wiley & Sons,2002 年,第 1374-1380 页。

Heitmeyer, C., “Software Cost Reduction,” in Encyclopedia of Software Engineering, J. J. Marciniak (ed.), 2 vols., John Wiley & Sons, 2002, pp. 1374–1380.

[赫尔18]

[Hel18]

Helfrich, J.,软件工程师的安全性, Chapman 和 Hall/CRC,2018 年。

Helfrich, J., Security for Software Engineers, Chapman and Hall/CRC, 2018.

[她06]

[Her06]

Hernan, S. 等人,“使用 STRIDE 方法发现安全设计缺陷”,MSDN 杂志, 2006 年 11 月。

Hernan, S., et al., “Uncover Security Design Flaws Using the STRIDE Approach,” MSDN Magazine, November 2006.

[Het84]

[Het84]

Hetzel, W.,《软件测试完整指南》, QED 信息科学,1984 年。

Hetzel, W., The Complete Guide to Software Testing, QED Information Sciences, 1984.

[希格02a]

[Hig02a]

Highsmith, J.(编辑),“伟大的方法论辩论:第 2 部分”,Cutter IT Journal,卷。15、没有。1、2002 年 1 月。

Highsmith, J. (ed.), “The Great Methodologies Debate: Part 2,” Cutter IT Journal, vol. 15, no. 1, January 2002.

[高95]

[Hig95]

Higuera, R.,“团队风险管理”,CrossTalk,美国国防部,1995 年 1 月,

第 2-4 页。

Higuera, R., “Team Risk Management,” CrossTalk, U.S. Dept. of Defense, January 1995,

pp. 2–4.

[希尔17]

[Hil17]

Hill, C. 等人,“性别包容性角色与刻板印象:我们可以两者兼得吗?” 2017 年 CHI 计算系统人为因素会议 (CHI '17) 会议论文集。ACM,纽约州纽约市,2017 年,第 6658–6671 页。

Hill, C., et al., “Gender-Inclusiveness Personas vs. Stereotyping: Can We Have It Both Ways?” Proceedings 2017 CHI Conference on Human Factors in Computing Systems (CHI ’17). ACM, New York, NY, 2017, pp. 6658–6671.

[Hne11]

[Hne11]

Hneif, M. 和 S. Lee,“使用指南提高软件非功能属性的质量”,IEEE Software,卷。28、没有。5,2011 年 11 月至 12 月,第 72-73 页。

Hneif, M., and S. Lee, “Using Guidelines to Improve Quality in Software Nonfunctional Attributes,” IEEE Software, vol. 28, no. 5, November–December 2011, pp. 72–73.

[锄头16]

[Hoe16]

Hoegl, M. 和 M. Muethel,“在虚拟项目团队中实现共享领导:从业者指南”,项目管理杂志,卷。47、没有。1,2016 年 2 月/3 月,第 7-12 页。

Hoegl, M., and M. Muethel, “Enabling Shared Leadership in Virtual Project Teams: A Practitioners’ Guide,” Project Management Journal, vol. 47, no. 1, February/March 2016, pp. 7–12.

[猪04]

[Hog04]

Hoglund, G. 和 G. McGraw,《利用软件:如何破解代码》, Addison-Wesley Professional,2004 年。

Hoglund, G., and G. McGraw, Exploiting Software: How to Break Code, Addison-Wesley Professional, 2004.

[霍尔06]

[Hol06]

Holzner, S.,《傻瓜设计模式》,傻瓜出版社,2006 年。

Holzner, S., Design Patterns for Dummies, For Dummies Publishers, 2006.

[呼12]

[Hoo12]

Hoober, S. 和 E. Berkman,设计移动界面, O'Reilly Media,2012 年。

Hoober, S., and E. Berkman, Designing Mobile Interfaces, O’Reilly Media, 2012.

[呼96]

[Hoo96]

Hooker, D.,“软件开发的七项原则”,1996 年 9 月,这些原则的摘要可在 https://lingualeo.com/pt/jungle/seven-principles-of-software-development-by-david- 上找到。 hooker-48432#/page/1.

Hooker, D., “Seven Principles of Software Development,” September 1996, a summary of these principles is available at https://lingualeo.com/pt/jungle/seven-principles-of-software-development-by-david-hooker-48432#/page/1.

[跳90]

[Hop90]

Hopper, M.,“Rattle SABRE,信息竞争的新方法”,《哈佛商业评论》, 1990 年 5 月至 6 月。

Hopper, M., “Rattling SABRE, New Ways to Compete on Information,” Harvard Business Review, May–June 1990.

[霍03]

[Hor03]

Horch, J.,软件质量管理实用指南,第二版,Artech House,2003 年。

Horch, J., Practical Guide to Software Quality Management, 2nd ed., Artech House, 2003.

[华17]

[Hua17]

Huang, J. 等人,“软件质量数据集的基于 K 最近邻插值的交叉验证:实证研究”,系统与软件杂志, 2017 年,第 226-252 页。

Huang, J., et al., “Cross-Validation Based K Nearest Neighbor Imputation for Software Quality Datasets: An Empirical Study,” Journal of Systems and Software, 2017, pp. 226–252.

[Hub99]

[Hub99]

Hubbard, R.,“设计、实施和评估构建软件项目需求集合的流程”,博士论文,科罗拉多技术大学,1999 年。

Hubbard, R., “Design, Implementation, and Evaluation of a Process to Structure the Collection of Software Project Requirements,” PhD dissertation, Colorado Technical University, 1999.

[Hus15]

[Hus15]

Hussain, A. 等人,“移动游戏应用程序的可用性评估:系统回顾”,国际计算机与信息技术杂志,卷。4、没有。3,2015 年 5 月,第 547-551 页。

Hussain, A., et al., “Usability Evaluation of Mobile Game Applications: A Systematic Review,” International Journal of Computer and Information Technology, vol. 4, no. 3, May 2015, pp. 547–551.

[海亚96]

[Hya96]

Hyatt, L. 和 L. Rosenberg,“用于识别项目风险和评估软件质量的软件质量模型和指标”,NASA SATC,1996 年,可访问 http://articles.adsabs.harvard.edu/cgi-bin/ nph-iarticle_query?1996ESASP.377..209H&data_type=PDF_HIGH&whole_paper=YES&type=PRINTER&filetype=.pdf。

Hyatt, L., and L. Rosenberg, “A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality,” NASA SATC, 1996, available at http://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_query?1996ESASP.377..209H&amp;data_type=PDF_HIGH&amp;whole_paper=YES&amp;type=PRINTER&amp;filetype=.pdf.

[IBM13]

[IBM13]

IBM,Web 服务全球化模型,2013 年,可从 ftp://public.dhe.ibm.com/software/globalization/.../webservicesglobalizationmodel.pdf 下载。

IBM, Web Services Globalization Model, 2013, downloadable from ftp://public.dhe.ibm.com/software/globalization/.../webservicesglobalizationmodel.pdf.

[IBM81]

[IBM81]

“实施软件检查”课程笔记,IBM 系统科学研究所,IBM 公司,1981 年。

“Implementing Software Inspections,” course notes, IBM Systems Sciences Institute, IBM Corporation, 1981.

[电气工程师05]

[IEE05]

IEEE 标准。982.1-2005,IEEE 软件可靠性方面测量标准词典, 2005 年。

IEEE Std. 982.1-2005, IEEE Standard Dictionary of Measures of the Software Aspects of Dependability, 2005.

[电气工程师学会11]

[IEE11]

第648页IEEE-Std-42010:2011(E),系统和软件工程架构描述, 2011 年,可在 https://ieeexplore.ieee.org/document/6129467 获取。

Page 648IEEE-Std-42010:2011(E), Systems and Software Engineering-Architectural Description, 2011, available at https://ieeexplore.ieee.org/document/6129467.

[IEE17]

[IEE17]

ISO/IEC/IEEE 24765:2017(E),ISO/IEC/IEEE 国际标准:系统和软件工程—词汇,可从 https://standards.ieee.org/findstds/standard/24765-2017.html 获取。

ISO/IEC/IEEE 24765:2017(E), ISO/IEC/IEEE International Standard: Systems and Software Engineering—Vocabulary, available at https://standards.ieee.org/findstds/standard/24765-2017.html.

[ISO08]

[ISO08]

ISO SPICE 2008,早期的描述可在 https://www.cs.helsinki.fi/u/paakki/Pyhajarvi.pdf 上找到。

ISO SPICE 2008, an earlier description is available at https://www.cs.helsinki.fi/u/paakki/Pyhajarvi.pdf.

[ISO14]

[ISO14]

ISO/IEC 90003:2014,第二版:软件工程 — ISO 9001:2008 计算机软件应用指南,国际标准化组织,2014 年。

ISO/IEC 90003:2014, Second Edition: Software Engineering—Guidelines for the Application of ISO 9001:2008 to Computer Software, International Organization for Standardization, 2014.

[ISO18]

[ISO18]

ISO/IEC/IEEE 90003:2018,软件工程 - ISO 9001:2015 在计算机软件中的应用指南,国际标准化组织,2018 年。

ISO/IEC/IEEE 90003:2018, Software Engineering—Guidelines for the Application of ISO 9001:2015 to Computer Software, International Organization for Standardization, 2018.

[ISO15]

[ISO15]

ISO 9001: 2015、2015 的简明英文摘要,可在 http://praxiom.com/iso-9001.htm 上获取。

Plain English Summary of ISO 9001: 2015, 2015, available at http://praxiom.com/iso-9001.htm.

[ISO11]

[ISO11]

ISO/IEC 25010:2011,系统和软件工程:系统和软件质量要求和评估 (SQuaRE) — 系统和软件质量模型,2011 年,可从 https://www.iso.org/standard/35733.html 获取。

ISO/IEC 25010:2011, Systems and Software Engineering: Systems and Software Quality Requirements and Evaluation (SQuaRE)—System and Software Quality Models, 2011, available at https://www.iso.org/standard/35733.html.

[伊夫04]

[Ive04]

Iversen, J.、L. Mathiassen 和 P. Nielsen,“管理软件流程改进中的风险:一种行动研究方法”,MIS 季刊,卷。28、没有。3,2004 年 9 月,第 395-433 页。

Iversen, J., L. Mathiassen, and P. Nielsen, “Managing Risk in Software Process Improvement: An Action Research Approach,” MIS Quarterly, vol. 28, no. 3, September 2004, pp. 395–433.

[伊沃01]

[Ivo01]

Ivory, M.、R. Sinha 和 M. Hearst,“经经验验证的网页设计指标”,ACM SIGCHI'01,2001 年 3 月 31 日至 4 月 4 日,可访问 http://webtango.berkeley.edu/papers/ chi2001/.

Ivory, M., R. Sinha, and M. Hearst, “Empirically Validated Web Page Design Metrics,” ACM SIGCHI’01, March 31–April 4, 2001, available at http://webtango.berkeley.edu/papers/chi2001/.

[雅克02a]

[Jac02a]

Jacobson, I.,“对敏捷流程的响亮‘是’——但还有更多”,Cutter IT Journal,卷。15、没有。1,2002 年 1 月,第 18-24 页。

Jacobson, I., “A Resounding ‘Yes’ to Agile Processes—But Also More,” Cutter IT Journal, vol. 15, no. 1, January 2002, pp. 18–24.

[Jac02b]

[Jac02b]

Jacyntho, D.、D. Schwabe 和 G. Rossi,“构建复杂 Web 应用程序的架构”,2002 年,可访问 https://www.semanticscholar.org/paper/A-Software-

Architecture-for-Structuring-复杂网络-Jacyntho-Schwabe/2809668ede5034ed8d65e7669c6b0b463e9ee464。

Jacyntho, D., D. Schwabe, and G. Rossi, “An Architecture for Structuring Complex Web Applications,” 2002, available at https://www.semanticscholar.org/paper/A-Software-

Architecture-for-Structuring-Complex-Web-Jacyntho-Schwabe/2809668ede5034ed8d65e7669c6b0b463e9ee464.

[江淮04]

[Jac04]

Jacobson, I. 和 P. Ng,面向方面的软件开发, Addison-Wesley,2004 年。

Jacobson, I., and P. Ng, Aspect-Oriented Software Development, Addison-Wesley, 2004.

[江淮92]

[Jac92]

Jacobson, I.,面向对象的软件工程, Addison-Wesley,1992。

Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley, 1992.

[江淮98]

[Jac98]

Jackman, M.,“针对团队毒性的顺势疗法”,IEEE Software, 1998 年 7 月,第 43-45 页。

Jackman, M., “Homeopathic Remedies for Team Toxicity,” IEEE Software, July 1998, pp. 43–45.

[江淮99]

[Jac99]

Jacobson, I.、G. Booch 和 J. Rumbaugh,《统一软件开发过程》, Addison-Wesley,1999 年。

Jacobson, I., G. Booch, and J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999.

[杰18]

[Jai18]

Jain, N. 等人,“数字消费者、新兴市场和 4 万亿美元的未来”,2018 年 9 月 18 日,网址:https://www.bcg.com/en-us/publications/2018/digital-消费者新兴市场 4 万亿美元未来.aspx。

Jain, N., et al., “Digital Consumers, Emerging Markets, and the $4 Trillion Future,” September 18, 2018, available at https://www.bcg.com/en-us/publications/2018/digital-consumers-emerging-markets-4-trillion-dollar-future.aspx.

[日04]

[Jal04]

Jalote, P. 等人,“时间盒:迭代软件开发的流程模型”,系统与软件杂志,卷。70,没有。2,2004 年,第 117-127 页。

Jalote, P., et al., “Timeboxing: A Process Model for Iterative Software Development,” Journal of Systems and Software, vol. 70, no. 2, 2004, pp. 117–127.

[果酱13]

[Jam13]

James, G. 等人,R 中应用统计学习简介, Springer,2013 年。

James, G., et al., An Introduction to Statistical Learning with Applications in R, Springer, 2013.

[1月16日]

[Jan16]

Jan, S. 等人,“研究各种软件测试技术和策略的创新方法”,国际科学、工程和技术科学研究杂志 (IJSRSET),卷。2、没有。2,2016 年 3 月至 4 月,第 682-689 页。

Jan, S., et al., “An Innovative Approach to Investigate Various Software Testing Techniques and Strategies,” International Journal of Scientific Research in Science, Engineering and Technology (IJSRSET), vol. 2, no. 2, March–April 2016, pp. 682–689.

[乔恩04]

[Jon04]

Jones, C.,“软件项目管理实践:失败与成功”,CrossTalk, 2004 年 10 月,可从 http://www.pauldee.org/se-must-have/jones-failure-success.pdf 获取。

Jones, C., “Software Project Management Practices: Failure Versus Success,” CrossTalk, October 2004, available at http://www.pauldee.org/se-must-have/jones-failure-success.pdf.

[乔恩86]

[Jon86]

Jones, C.,《编程效率》, McGraw-Hill,1986 年。

Jones, C., Programming Productivity, McGraw-Hill, 1986.

[乔恩91]

[Jon91]

Jones, C.,使用 VDM 进行系统软件开发,第 2 版,Prentice Hall,1991 年。

Jones, C., Systematic Software Development Using VDM, 2nd ed., Prentice Hall, 1991.

[乔夫15]

[Jov15]

Jovanovic M.、A. Mesquida 和 A. Mas,“敏捷软件开发中通过回顾游戏进行流程改进”,系统、软件和服务流程改进, EuroSPI 2015 计算机和信息科学通讯,R. O'Connor 等人。(编辑),卷。543,施普林格,2015。

Jovanovic M., A. Mesquida, and A. Mas, “Process Improvement with Retrospective Gaming in Agile Software Development,” Systems, Software and Services Process Improvement, EuroSPI 2015 Communications in Computer and Information Science, R. O’Connor, et al. (eds.), vol. 543, Springer, 2015.

[欢乐00]

[Joy00]

Joy, B.,“未来不需要我们”,《连线》,卷。8、不。4、2000 年 4 月。

Joy, B., “The Future Doesn’t Need Us,” Wired, vol. 8, no. 4, April 2000.

[看01]

[Kan01]

Kaner, C.,“模式:场景测试”(草案),2001 年,可从 http://www.exampler.com/testing-com/test-patterns/patterns/pattern-scenario-testing-kaner.html 获取。

Kaner, C., “Pattern: Scenario Testing” (draft), 2001, available at http://www.exampler.com/testing-com/test-patterns/patterns/pattern-scenario-testing-kaner.html.

[看93]

[Kan93]

Kaner, C.、J. Falk 和 HQ Nguyen,测试计算机软件,第二版,Van Nostrand-Reinhold,1993 年。

Kaner, C., J. Falk, and H. Q. Nguyen, Testing Computer Software, 2nd ed., Van Nostrand-Reinhold, 1993.

[看95]

[Kan95]

Kaner, C.,“律师、诉讼和质量相关成本”,1995 年,可访问 www.badsoftware.com/plaintif.htm。

Kaner, C., “Lawyers, Lawsuits, and Quality Related Costs,” 1995, available at www.badsoftware.com/plaintif.htm.

[卡普15]

[Kap15]

Kapyaho, M. 和 M. Kauppinen,“带有原型的敏捷需求工程:案例研究”,IEEE 第 23 届国际需求工程会议论文集, 2015 年 8 月,加拿大安大略省,第 334-343 页。

Kapyaho, M., and M. Kauppinen, “Agile Requirements Engineering with Prototyping: A Case Study,” Proceedings IEEE 23rd International Requirements Engineering Conference, August 2015, ON, Canada, pp. 334–343.

[卡尔12]

[Kar12]

第649页Kar S.、S. Das、A. Kumar Rath 和 SK Kar,“SPICE 的自我评估模型和审查技术:SMART SPICE”,《软件过程改进和能力确定》, A. Mas 等人。(编辑),SPICE 2012,计算机和信息科学通信,卷。290,2012年,施普林格,柏林,海德堡。

Page 649Kar S., S. Das, A. Kumar Rath, and S. K. Kar, “Self-assessment Model and Review Technique for SPICE: SMART SPICE,” in Software Process Improvement and Capability Determination, A. Mas et al. (eds.), SPICE 2012, Communications in Computer and Information Science, vol. 290, 2012, Springer, Berlin, Heidelberg.

[卡尔94]

[Kar94]

Karten, N.,管理期望,多塞特宫,1994 年。

Karten, N., Managing Expectations, Dorset House, 1994.

[考11]

[Kau11]

Kaur, A. 和 S. Goel,“基于组件的软件开发中 COTS 组件的使用风险”。国际信息技术和知识管理杂志,卷。4、没有。2,2011 年 7 月至 12 月,第 573-575 页。

Kaur, A., and S. Goel, “COTS Components Usage Risks in Component Based Software Development.” International Journal of Information Technology and Knowledge Management, vol. 4, no. 2, July–December 2011, pp. 573–575.

[卡兹98]

[Kaz98]

Kazman, R. 等人,《架构权衡分析方法》,软件工程学院,CMU/SEI-98-TR-008,1998 年 7 月,总结于 http://www.sei.cmu.edu/architecture/tools/评估/atam.cfm。

Kazman, R., et al., The Architectural Tradeoff Analysis Method, Software Engineering Institute, CMU/SEI-98-TR-008, July 1998, summarized at http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm.

[凯亚07]

[Kea07]

Keane,“测试移动业务应用程序”白皮书,2007 年。可在 https://softcrylic.com/blogs/40-point-checklist-testing-mobile-applications/ 上获取补充本白皮书的 40 点清单。

Keane, “Testing Mobile Business Applications,” a white paper, 2007. A 40-point checklist that complements this white paper is available at https://softcrylic.com/blogs/40-point-checklist-testing-mobile-applications/.

[惠18]

[Kei18]

Keith, J.,“UI 设计模式的 10 个优秀网站”,2018 年,可访问 https://www.interaction-design.org/literature/article/10-great-sites-for-ui-design-patterns。

Keith, J., “10 Great Sites for UI Design Patterns,” 2018, available at https://www.interaction-design.org/literature/article/10-great-sites-for-ui-design-patterns.

[庆98]

[Kei98]

Keil, M. 等人,“识别软件项目风险的框架”,CACM,卷。41、没有。11,1998 年 11 月,第 76-83 页。

Keil, M., et al., “A Framework for Identifying Software Project Risks,” CACM, vol. 41, no. 11, November 1998, pp. 76–83.

[Ker17]

[Ker17]

Kerzner, H.,项目管理:规划、调度和控制的系统方法,第 12 版,Wiley,2017 年。

Kerzner, H., Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 12th ed., Wiley, 2017.

[科12]

[Kho12]

Khode, A.,“移动应用程序测试入门”,2012 年,可在 http://www.

mobileappstesting.com/getting-started-with-mobile-apps-testing/。

Khode, A., “Getting Started with Mobile Apps Testing,” 2012, available at http://www.

mobileappstesting.com/getting-started-with-mobile-apps-testing/.

[金16a]

[Kim16a]

Kim, G. 等人,《DevOps 手册:如何在技术组织中创建世界一流的敏捷性、可靠性和安全性》, Revolution Press,2016 年。

Kim, G., et al., The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, Revolution Press, 2016.

[金16b]

[Kim16b]

Kim, M. 等人,“数据科学家在软件开发团队中的新兴角色”,第 38 届国际软件工程会议 (ICSE '16) 论文集。ACM,纽约州,2016 年,第 96-107 页。

Kim, M., et al., “The Emerging Role of Data Scientists on Software Development Teams,” Proceedings 38th International Conference on Software Engineering (ICSE ’16). ACM, New York, NY, 2016, pp. 96–107.

[基尔94]

[Kir94]

Kirani, S. 和 W. Tsai,“面向对象程序的规范和验证”,技术报告 TR 94-64,明尼苏达大学计算机科学系,1994 年 12 月。

Kirani, S., and W. Tsai, “Specification and Verification of Object-Oriented Programs,” Technical Report TR 94-64, Computer Science Department, University of Minnesota, December 1994.

[Kiz05]

[Kiz05]

Kizza, J.,计算机网络安全, Springer,2005 年。

Kizza, J., Computer Network Security, Springer, 2005.

[Kna16]

[Kna16]

Knapp, J.、J. Zeratsky 和 ​​B. Kowitz,《Sprint: 如何在短短五天内解决大问题并测试新想法》, Simon 和 Schuster,2016 年。

Knapp, J., J. Zeratsky, and B. Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon and Schuster, 2016.

[科伊12]

[Koe12]

Koester, J.,“移动应用设计的七宗罪”,Venture Beat/Mobile, 2012 年 5 月 31 日,网址为:http://venturebeat.com/2012/05/31/the-7-deadly-sins-of -移动应用程序设计/。

Koester, J., “The Seven Deadly Sins of MobileApp Design,” Venture Beat/Mobile, May 31, 2012, available at http://venturebeat.com/2012/05/31/the-7-deadly-sins-of-mobile-app-design/.

[科尔03]

[Kor03]

Korpipaa, P. 等人,“管理移动设备中的上下文信息”,IEEE 普适计算,卷。2、没有。3,2003 年 7 月至 9 月,第 42-51 页。

Korpipaa, P., et al., “Managing Context Information in Mobile Devices,” IEEE Pervasive Computing, vol. 2, no. 3, July–September 2003, pp. 42–51.

[寇14]

[Kou14]

Kouzes, J.,模范领导力的五种实践——技术, Wiley,2014 年。

Kouzes, J., Five Practices of Exemplary Leadership—Technology, Wiley, 2014.

[克拉88]

[Kra88]

Krasner, G. 和 S. Pope,“在 Smalltalk-80 中使用模型-视图控制器用户界面范例的手册”,《面向对象编程杂志》,卷。1、没有。3,1988 年 8 月至 9 月,第 26-49 页。

Krasner, G., and S. Pope, “A Cookbook for Using the Model-View Controller User Interface Paradigm in Smalltalk-80,” Journal of Object-Oriented Programming, vol. 1, no. 3, August–September 1988, pp. 26–49.

[克拉95]

[Kra95]

Kraul, R. 和 L. Streeter,“软件开发中的协调”,CACM,卷。38,没有。3,1995 年 3 月,第 69-81 页。

Kraul, R., and L. Streeter, “Coordination in Software Development,” CACM, vol. 38, no. 3, March 1995, pp. 69–81.

[克鲁05]

[Kru05]

Krutchen, P.,“后现代时代的软件设计”,IEEE Software,卷。22、没有。2,2005

年 3 月至 4 月,第 16-18 页。

Krutchen, P., “Software Design in a Postmodern Era,” IEEE Software, vol. 22, no. 2,

March–April 2005, pp. 16–18.

[克鲁06]

[Kru06]

Kruchten, P.、H. Obbink 和 J. Stafford(编),“软件架构”(特刊),IEEE 软件,卷。23、没有。2、2006 年 3 月至 4 月。

Kruchten, P., H. Obbink, and J. Stafford (eds.), “Software Architectural” (special issue), IEEE Software, vol. 23, no. 2, March–April 2006.

[克鲁09]

[Kru09]

Kruchten, P. 等人,“决策视图在软件架构实践中的作用”,IEEE Software,卷。26、没有。2,2009 年 3 月至 4 月,第 70-72 页。

Kruchten, P., et al., “The Decision View’s Role in Software Architecture Practice,” IEEE Software, vol. 26, no. 2, March–April 2009, pp. 70–72.

[库布17]

[Kub17]

Kubat, M.,机器学习简介,第二版,Springer,2017 年。

Kubat, M., An Introduction to Machine Leaning, 2nd ed., Springer, 2017.

[库尔13]

[Kul13]

Kulkarni, V.,“模型驱动软件开发”,建模基础和应用, ECMFA 2013。计算机科学讲义,Van Gorp 等人。(编辑),卷。7949,施普林格,2013。

Kulkarni, V., “Model Driven Software Development,” Modelling Foundations and Applications, ECMFA 2013. Lecture Notes in Computer Science, Van Gorp, et al. (eds.), vol. 7949, Springer, 2013.

[库尔05]

[Kur05]

Kurzweil, R.,《奇点临近》,企鹅图书,2005 年。

Kurzweil, R., The Singularity Is Near, Penguin Books, 2005.

[库尔13]

[Kur13]

Kurzweil, R.,《如何创造思维》,维京人,2013 年。

Kurzweil, R., How to Create a Mind, Viking, 2013.

[Kyb84]

[Kyb84]

Kyburg, H.,《理论与测量》,剑桥大学出版社,1984 年。

Kyburg, H., Theory and Measurement, Cambridge University Press, 1984.

[Laa00]

[Laa00]

Laakso, S. 等人,“改进的滚动条”,载于CHI '00 计算系统中人为因素扩展摘要 (CHI EA '00)。ACM,纽约,2000 年,第 97-98 页。

Laakso, S., et al., “Improved Scroll Bars,” In CHI ’00 Extended Abstracts on Human Factors in Computing Systems (CHI EA ’00). ACM, New York, NY, 2000, pp. 97–98.

[滞后10]

[Lag10]

第650页Lago, P. 等人,“软件架构:构建利益相关者的关注点”,IEEE Software,卷。27、没有。6,2010 年 11 月至 12 月,第 20-24 页。

Page 650Lago, P., et al., “Software Architecture: Framing Stakeholders’ Concerns,” IEEE Software, vol. 27, no. 6, November–December 2010, pp. 20–24.

[赖02]

[Lai02]

Laitenberger, A.,“软件检查技术调查”,《软件工程和知识工程手册》,世界科学出版公司,2002 年。

Laitenberger, A., “A Survey of Software Inspection Technologies,” in Handbook on Software Engineering and Knowledge Engineering, World Scientific Publishing Company, 2002.

[林09]

[Lam09]

Lamsweerde, A.,“面向目标的需求工程:引导之旅”,第五届 IEEE 国际需求工程研讨会论文集,多伦多,2009 年 8 月,第 249-263 页。

Lamsweerde, A., “Goal-Oriented Requirements Engineering: A Guided Tour,” Proceedings of 5th IEEE International Symposium on Requirements Engineering, Toronto, August 2009, pp. 249–263.

[兰01]

[Lan01]

Lange, M.,“测试时间到了!测试软件的模式”,2001 年 6 月,可从 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.5064&rep=rep1&type=pdf 获取。

Lange, M., “It’s Testing Time! Patterns for Testing Software,” June 2001, available at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.5064&rep=rep1&type=pdf.

[拉尔16]

[Lar16]

Larrucea, X. 等人,“小型组织中的软件流程改进”,IEEE Software,卷。33、没有。2,2016 年 3 月至 4 月,第 85-89 页。

Larrucea, X., et al., “Software Process Improvement in Very Small Organizations,” IEEE Software, vol. 33, no. 2, March–April 2016, pp. 85–89.

[拉兹11]

[Laz11]

Lazzaroni, M. 等人,可靠性工程, Springer,2011 年。

Lazzaroni, M., et al., Reliability Engineering, Springer, 2011.

[列赫97a]

[Leh97a]

Lehman, M. 和 L. Belady,程序演化:软件变更过程,学术出版社,1997 年。

Lehman, M., and L. Belady, Program Evolution: Processes of Software Change, Academic Press, 1997.

[Leh97b]

[Leh97b]

Lehman, M. 等人,“软件演进的度量和法则 - 九十年代观点”,第四届国际软件度量研讨会论文集 (METRICS '97), IEEE,1997 年,可从 www.ece.utexas.edu/~perry 获取/work/papers/feast1.pdf。

Lehman, M., et al., “Metrics and Laws of Software Evolution—The Nineties View,” Proceedings 4th International Software Metrics Symposium (METRICS ’97), IEEE, 1997, available at www.ece.utexas.edu/~perry/work/papers/feast1.pdf.

[让04]

[Let04]

Lethbridge, T. 和 R. Lagraniere,面向对象软件工程;使用 UML 和 Java 进行实用软件开发,第二版,McGraw-Hill,2004 年。

Lethbridge, T., and R. Lagraniere, Object-Oriented Software Engineering; Practical Software Development Using UML and Java, 2nd ed., McGraw-Hill, 2004.

[列01]

[Lev01]

Levinson, M.,“让我们停止每年浪费 780 亿美元”,CIO 杂志, 2001 年 10 月 15 日,网址:https://www.cio.com/article/2441228/software-development---let-s-stop -浪费--

每年780亿.html。

Levinson, M., “Let’s Stop Wasting $78 billion a Year,” CIO Magazine, October 15, 2001, available at https://www.cio.com/article/2441228/software-development---let-s-stop-wasting--

78-billion-a-year.html.

[12级]

[Lev12]

Leveson, N.,工程一个更安全的世界:应用于安全的系统思维(工程系统),麻省理工学院出版社,2012 年。

Leveson, N., Engineering a Safer World: Systems Thinking Applied to Safety (Engineering Systems), MIT Press, 2012.

[李16]

[Li16]

Li, W., Z. Huang, 和 Q. Li,“基于三向决策的软件缺陷预测”,基于知识的系统,卷。91,2016 年,第 263-274 页。

Li, W., Z. Huang, and Q. Li, “Three-Way Decisions Based Software Defect Prediction,” Knowledge-Based Systems, vol. 91, 2016, pp. 263–274.

[林16]

[Lin16]

Lin, Y. 等人,“基于搜索的推荐进行交互式和引导式架构重构”,第 24 届 ACM SIGSOFT 软件工程基础国际研讨会论文集, 2016 年 11 月,第 535-546 页。

Lin, Y., et al., “Interactive and Guided Architectural Refactoring with Search-Based Recommendation,” Proceedings 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, November 2016, pp. 535–546.

[林79]

[Lin79]

Linger, R.、H. Mills 和 B. Witt,《结构化编程》, Addison-Wesley,1979 年。

Linger, R., H. Mills, and B. Witt, Structured Programming, Addison-Wesley, 1979.

[李斯88]

[Lis88]

Liskov, B.,“数据抽象和层次结构”,SIGPLAN 公告,卷。23、没有。5、1988 年 5 月。

Liskov, B., “Data Abstraction and Hierarchy,” SIGPLAN Notices, vol. 23, no. 5, May 1988.

[玛阿07]

[Maa07]

Maassen, O. 和 S. Stelting,“创建模式:在 OO 系统中创建对象”,2007 年,可从 www.informit.com/articles/article.asp?p=26452&rl=1 获取。

Maassen, O., and S. Stelting, “Creational Patterns: Creating Objects in an OO System,” 2007, available at www.informit.com/articles/article.asp?p=26452&rl=1.

[Mac10]

[Mac10]

Maciel, C. 等人,“基于测试模式和 MDA 技术的集成测试方法”,第8 届拉丁美洲程序模式语言会议 (SugarLoafPLoP '10), ACM,纽约,第 14 条,2010 年。

Maciel, C., et al., “An Integration Testing Approach Based on Test Patterns and MDA Techniques,” Proceedings 8th Latin American Conference on Pattern Languages of Programs (SugarLoafPLoP ’10), ACM, New York, NY, Article 14, 2010.

[马尔16]

[Mal16]

Malhotra, R.,“使用机器学习技术和 Android 软件进行缺陷预测的经验框架”,应用软件计算,卷。49,2016 年 12 月,第 1034–1050 页。

Malhotra, R., “An Empirical Framework for Defect Prediction Using Machine Learning Techniques with Android Software,” Applied Software Computing, vol. 49, December 2016, pp. 1034–1050.

[马尔17]

[Mal17]

Malhotra, R.、M. Khanna 和 R. Raje,“基于搜索的技术在软件工程预测建模中的应用:系统回顾和未来方向”,群体与进化计算,卷。32,2017 年 2 月,第 85-109 页。

Malhotra, R., M. Khanna, and R. Raje, “On the Application of Search-Based Techniques for Software Engineering Predictive Modeling: A Systematic Review and Future Directions,” Swarm and Evolutionary Computation, vol. 32, February 2017, pp. 85–109.

[男人17]

[Man17]

Mansoor, U. 等人,“使用多目标进化算法对类和活动图进行多视图重构”,《软件质量杂志》,卷。25、没有。2,2017 年,第 529–552 页。

Mansoor, U., et al., “Multi-view Refactoring of Class and Activity Diagrams Using a Multi-Objective Evolutionary Algorithm,” Software Quality Journal, vol. 25, no. 2, 2017, pp. 529–552.

[男人81]

[Man81]

Mantai, M.,“编程团队结构对编程任务的影响”,CACM,卷。24、没有。3,1981 年 3 月,第 106-113 页。

Mantai, M., “The Effect of Programming Team Structures on Programming Tasks,” CACM, vol. 24, no. 3, March 1981, pp. 106–113.

[男人97]

[Man97]

Mandel, T.,用户界面设计要素, Wiley,1997。

Mandel, T., The Elements of User Interface Design, Wiley, 1997.

[毛17]

[Mao17]

Mao, K.、M. Harman 和 Y. Jia,“群体智能增强自动化移动测试”,第 32 届 IEEE/ACM 国际自动化软件工程会议论文集 (ASE 2017), IEEE Press,皮斯卡塔韦,新泽西州,2017 年,第 32 页。 16-26。

Mao, K., M. Harman, and Y. Jia, “Crowd Intelligence Enhances Automated Mobile Testing,” Proceedings 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE 2017), IEEE Press, Piscataway, NJ, 2017, pp. 16–26.

[3月00日]

[Mar00]

Martin, R.,“设计原则和设计模式”,2000 年,可访问 https://fi.ort.edu.uy/innovaportal/file/2032/1/design_principles.pdf。

Martin, R., “Design Principles and Design Patterns,” 2000, available at https://fi.ort.edu.uy/innovaportal/file/2032/1/design_principles.pdf.

[3月2日]

[Mar02]

Marick, B.,“软件测试模式”,2002 年。

Marick, B., “Software Testing Patterns,” 2002.

[94 年 3 月]

[Mar94]

Marick, B.,《软件测试技巧》, Prentice Hall,1994 年。

Marick, B., The Craft of Software Testing, Prentice Hall, 1994.

[垫94]

[Mat94]

Matson, J. 等人,“使用功能点进行软件成本估算”,IEEE 软件工程汇刊,卷。20、没有。4,1994 年 4 月,第 275-287 页。

Matson, J., et al., “Software Cost Estimation Using Function Points,” IEEE Transactions on Software Engineering, vol. 20, no. 4, April 1994, pp. 275–287.

[最多16]

[Max16]

Maxim, BR 和 M. Kessentini,“现代软件质量保证简介”,《软件质量保证》, I. Mistrik 等人。(编辑),摩根考夫曼,2016 年,第 19-46 页。

Maxim, B. R., and M. Kessentini, “An Introduction to Modern Software Quality Assurance,” in Software Quality Assurance, I. Mistrik et al. (eds.), Morgan Kaufman, 2016, pp. 19–46.

[麦科09]

[McC09]

第651页McCaffrey, J.,“利用 PERIL 分析风险暴露和风险”,MSDN 杂志, 2009 年 1 月,网址为:http://msdn.microsoft.com/en-us/magazine/dd315417.aspx。

Page 651McCaffrey, J., “Analyzing Risk Exposure and Risk Using PERIL,” MSDN Magazine, January 2009, available at http://msdn.microsoft.com/en-us/magazine/dd315417.aspx.

[麦C76]

[McC76]

McCabe, T.,“软件复杂性度量”,IEEE 软件工程汇刊,卷。SE-2,1976 年 12 月,第 308-320 页。

McCabe, T., “A Software Complexity Measure,” IEEE Transactions on Software Engineering, vol. SE-2, December 1976, pp. 308–320.

[麦C77]

[McC77]

McCall, J.、P. Richards 和 G. Walters,“软件质量的因素”,三卷,NTIS AD-A049-014, 015, 055,1977 年 11 月。

McCall, J., P. Richards, and G. Walters, “Factors in Software Quality,” three volumes, NTIS AD-A049-014, 015, 055, November 1977.

[麦C96]

[McC96]

McConnell, S.,“最佳实践:每日构建和冒烟测试”,IEEE Software,卷。13、没有。4,1996 年 7 月,第 143-144 页。

McConnell, S., “Best Practices: Daily Build and Smoke Test,” IEEE Software, vol. 13, no. 4, July 1996, pp. 143–144.

[麦格06]

[McG06]

McGraw, G.,软件安全:构建安全性, Addison-Wesley Professional,2006 年。

McGraw, G., Software Security: Building Security In, Addison-Wesley Professional, 2006.

[麦G91]

[McG91]

McGlaughlin, R.,“程序设计的一些注释”,软件工程注释,卷。16、没有。4,1991 年 10 月,第 53-54 页。

McGlaughlin, R., “Some Notes on Program Design,” Software Engineering Notes, vol. 16, no. 4, October 1991, pp. 53–54.

[麦G94]

[McG94]

McGregor, J. 和 T. Korson,“集成的面向对象测试和开发过程”,CACM,卷。37、没有。9,1994 年 9 月,第 59-77 页。

McGregor, J., and T. Korson, “Integrated Object-Oriented Testing and Development Processes,” CACM, vol. 37, no. 9, September, 1994, pp. 59–77.

[麦K17]

[McK17]

McKinney, W.,《Python 数据分析与 Pandas、NumPy 和 IPython 的数据整理》, O'Reilly Media,2017 年。

McKinney, W., Python for Data Analysis Data Wrangling with Pandas, NumPy, and IPython, O’Reilly Media, 2017.

[麦克T16]

[McT16]

McTear, M.、Z. Callejas 和 D. Griol,对话界面:与智能设备对话, Springer,2016 年。

McTear, M., Z. Callejas, and D. Griol, The Conversational Interface: Talking to Smart Devices, Springer, 2016.

[Mea05]

[Mea05]

Mead, N.、E. Hough 和 T. Stehney,“安全质量需求工程 (SQUARE) 方法”(CMU/SEI-2005-TR-009、ADA452453),宾夕法尼亚州匹兹堡:卡内基梅隆大学软件工程学院, 2005 年,可访问 http://www.sei.cmu.edu/publications/documents/05.reports/05tr009.html。

Mead, N., E. Hough, and T. Stehney, “Security Quality Requirements Engineering (SQUARE) Methodology” (CMU/SEI-2005-TR-009, ADA452453), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005, available at http://www.sei.cmu.edu/publications/documents/05.reports/05tr009.html.

[Mea16]

[Mea16]

Mead, N. 和 C. Woody,网络安全工程:系统和软件保障的实用方法, Addison-Wesley,2016 年。

Mead, N., and C. Woody, Cyber Security Engineering: A Practical Approach for Systems and Software Assurance, Addison-Wesley, 2016.

[Mea18]

[Mea18]

Mead, N. 等人,“混合威胁建模方法”,软件工程研究所 CMU/SEI 报告编号:CMU/SEI-2018-TN-002,2018 年 3 月,可从 https://resources.sei.cmu 下载.edu/asset_files/TechnicalNote/2018_004_001_516627.pdf。

Mead, N., et al., “A Hybrid Threat Modeling Method,” Software Engineering Institute CMU/SEI Report Number: CMU/SEI-2018-TN-002, March 2018, downloadable at https://resources.sei.cmu.edu/asset_files/TechnicalNote/2018_004_001_516627.pdf.

[梅09]

[Mei09]

Meier, J. 等人,《Microsoft 应用程序架构指南》,第 2 版,Microsoft Press,2009 年,可从 http://msdn.microsoft.com/en-us/library/ff650706 获取。

Meier, J., et al., Microsoft Application Architecture Guide, 2nd ed., Microsoft Press, 2009, available at http://msdn.microsoft.com/en-us/library/ff650706.

[梅12]

[Mei12]

Meier, J. 等人,“第 19 章:移动应用程序”,应用程序架构指南,2.0,2012年,可从 https://guidanceshare.com/wiki/Application_Architecture_Guide_-_Chapter_19_-_Mobile_Applications 获取。

Meier, J., et al., “Chapter 19: Mobile Applications,” Application Architecture Guide, 2.0, 2012, available at https://guidanceshare.com/wiki/Application_Architecture_Guide_-_Chapter_19_-_Mobile_Applications.

[梅18]

[Mei18]

Meinke, K. 和 A. Bennaceur,“软件工程机器学习:模型、方法和应用”,第40 届国际软件工程会议论文集:配套论文集 (ICSE '18)。美国CM,2018。

Meinke, K., and A. Bennaceur, “Machine Learning for Software Engineering: Models, Methods, and Applications,” Proceedings of the 40th International Conference on Software Engineering: Companion Proceeding (ICSE ’18). ACM, 2018.

[梅尔06]

[Mel06]

Mellado, D. 等人,《应用安全需求工程流程》, Springer,2006 年,可从 https://pdfs.semanticscholar.org/379f/941eaf2878341948fbc30f6da246d90702ab.pdf 获取。

Mellado, D., et al., Applying a Security Requirements Engineering Process, Springer, 2006, available at https://pdfs.semanticscholar.org/379f/941eaf2878341948fbc30f6da246d90702ab.pdf.

[男01]

[Men01]

Mendes, E.、N. Mosley 和 S. Counsell,“估计设计和创作工作量”,IEEE 多媒体,卷。8、不。1,2001 年 1 月至 3 月,第 50-57 页。

Mendes, E., N. Mosley, and S. Counsell, “Estimating Design and Authoring Effort,” IEEE Multimedia, vol. 8, no. 1, January–March 2001, pp. 50–57.

[男装13]

[Men13]

Menzies, T. 和 T. Zimmermann,“软件分析:那又怎样?” IEEE 软件,卷。30,没有。4,2013 年 7 月,第 31-37 页。

Menzies, T., and T. Zimmermann, “Software Analytics: So What?” IEEE Software, vol. 30, no. 4, July 2013, pp. 31–37.

[梅尔93]

[Mer93]

Merlo, E. 等人,“重新设计用户界面”,IEEE Software, 1993 年 1 月,第 64-73 页。

Merlo, E., et al., “Reengineering User Interfaces,” IEEE Software, January 1993, pp. 64–73.

[麦克风04]

[Mic04]

Microsoft,“规范架构:集成和模式”,MSDN, 2004 年 5 月,网址为:http://msdn2.microsoft.com/en-us/library/ms978700.aspx。

Microsoft, “Prescriptive Architecture: Integration and Patterns,” MSDN, May 2004, available at http://msdn2.microsoft.com/en-us/library/ms978700.aspx.

[麦克风09]

[Mic09]

Microsoft 模式与实践团队,Microsoft 应用程序架构指南,第二版,Microsoft Press,2009 年。

Microsoft Patterns & Practices Team, Microsoft Application Architecture Guide, 2nd ed., Microsoft Press, 2009.

[麦克风10]

[Mic10]

Microsoft 安全开发生命周期版本 5.0,2010,可从 http://download.microsoft.com/download/F/2/0/F205C451-C59C-4DC7-8377-9535D0A208EC/Microsoft%20SDL_Version%205.0.docx 获取。

Microsoft Security Development Lifecycle Version 5.0, 2010, available at http://download.microsoft.com/download/F/2/0/F205C451-C59C-4DC7-8377-9535D0A208EC/Microsoft%20SDL_Version%205.0.docx.

[麦克风13a]

[Mic13a]

Microsoft Accessibility Technology forEveryone,2013,可从 www.microsoft.com/enable/ 获取。

Microsoft Accessibility Technology for Everyone, 2013, available at www.microsoft.com/enable/.

[麦克风13b]

[Mic13b]

Microsoft,“模式与实践”,MSDN, 2013 年,网址为:http://msdn.microsoft.com/en-us/library/ff647589.aspx。

Microsoft, “Patterns and Practices,” MSDN, 2013, available at http://msdn.microsoft.com/en-us/library/ff647589.aspx.

[麦克风17]

[Mic17]

Microsoft Corporation,“SDL 威胁建模工具”,安全开发生命周期, 2017 年 11 月 10 日,网址为 https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx。

Microsoft Corporation, “SDL Threat Modeling Tool,” Security Development Lifecycle, November 10, 2017, available at https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx.

[麦克风18]

[Mic18]

Microsoft 安全开发生命周期 (SDL),可从 https://www.microsoft.com/en-us/securityengineering/sdl/ 获取,Microsoft,2018。

The Microsoft Security Development Lifecycle (SDL), available at https://www.microsoft.com/en-us/securityengineering/sdl/, Microsoft, 2018.

[米尔00]

[Mil00]

Mili, A. 和 R. Cowan,“软件工程技术观察”,2000 年 4 月 6 日,可访问 https://www.researchgate.net/publication/222828018_Software_engineering_technology_watch。

Mili, A., and R. Cowan, “Software Engineering Technology Watch,” April 6, 2000, available at https://www.researchgate.net/publication/222828018_Software_engineering_technology_watch.

[军04]

[Mil04]

第652页Miler, J. 和 J. Gorski,“软件项目的风险识别模式”,计算和决策科学基础,卷。29、没有。1,2004 年,第 115-131 页,可在 http://iag.pg.gda.pl/RiskGuide/papers/Miler-Gorski_Risk_Identification_Patterns.pdf 获取。

Page 652Miler, J., and J. Gorski, “Risk Identification Patterns for Software Projects,” Foundations of Computing and Decision Sciences, vol. 29, no. 1, 2004, pp. 115–131, available at http://iag.pg.gda.pl/RiskGuide/papers/Miler-Gorski_Risk_Identification_Patterns.pdf.

[米尔72]

[Mil72]

Mills, H.,“结构化编程的数学基础”,技术报告 FSC 71-6012,IBM 公司,联邦系统部门,马里兰州盖瑟斯堡,1972 年。

Mills, H., “Mathematical Foundations for Structured Programming,” Technical Report FSC 71-6012, IBM Corp., Federal Systems Division, Gaithersburg, MD, 1972.

[MIT14]

[Mit14]

Mitre Corp.,“常见弱点枚举:社区开发的软件弱点类型词典”,2014 年,可从 http://cwe.mitre.org 获取。

Mitre Corp., “Common Weakness Ennumeration: A Community-Developed Dictionary of Software Weakness Types,” 2014, available at http://cwe.mitre.org.

[生物12]

[Mob12]

“移动 UI 模式”,2012 年,可在 http://mobile-patterns.com/ 获取。

“Mobile UI Patterns,” 2012, available at http://mobile-patterns.com/.

[财政部04]

[Mof04]

Moffett, J. 等人,“核心安全要求工件”,技术报告 2004/23。英国米尔顿凯恩斯:开放大学计算系,2004 年 6 月,可访问 http://computing.open.ac.uk。

Moffett, J., et al., “Core Security Requirements Artefacts,” Technical Report 2004/23. Milton Keynes, UK: Department of Computing, The Open University, June 2004, available at http://computing.open.ac.uk.

[摩尔12]

[Mol12]

Molitor, M.,“软件配置管理和持续集成”,2012 年,参见 https://sewiki.iai.uni-bonn.de/_media/teaching/labs/xp/2012b/seminar/6-scm.pdf。

Molitor, M., “Software Configuration Management and Continuous Integration,” 2012, available at https://sewiki.iai.uni-bonn.de/_media/teaching/labs/xp/2012b/seminar/6-scm.pdf.

[摩尔05]

[Mor05]

Morales, A.,“梦之队”,Dr. Dobbs Portal,2005 年 3 月 3 日,可访问 www.ddj.com/dept/global/184415303。

Morales, A., “The Dream Team,” Dr. Dobbs Portal, March 3, 2005, available at www.ddj.com/dept/global/184415303.

[莫尔81]

[Mor81]

Moran, T.,“命令语言语法:交互式计算机系统用户界面的表示”,国际人机研究杂志,卷。1981 年 15 月,第 3-50 页。

Moran, T., “The Command Language Grammar: A Representation for the User Interface of Interactive Computer Systems,” International Journal of Man-Machine Studies, vol. 15, 1981, pp. 3–50.

[文17]

[Mun17]

Munaiah, N. 等人,“Bug 是否预示着漏洞?Chromium 项目的深入研究,《实证软件工程》,卷。2017 年 22 月,第 1305–1347 页。

Munaiah, N., et al., “Do Bugs Foreshadow Vulnerabilities? An In-depth Study of the Chromium Project,” Empirical Software Engineering, vol. 22, 2017, pp. 1305–1347.

[穆斯87]

[Mus87]

Musa, J.、A. Iannino 和 K. Okumoto,《采用可靠性措施设计和管理软件》, McGraw-Hill,1987 年。

Musa, J., A. Iannino, and K. Okumoto, Engineering and Managing Software with Reliability Measures, McGraw-Hill, 1987.

[Mye78]

[Mye78]

Myers, G.,复合结构设计, Van Nostrand,1978。

Myers, G., Composite Structured Design, Van Nostrand, 1978.

[Mye79]

[Mye79]

Myers, G.,《软件测试的艺术》, Wiley,1979 年。

Myers, G., The Art of Software Testing, Wiley, 1979.

[南14]

[Nan14]

Ramanathan, N.、A. Lal 和 R. Parmar,“软件质量保证的最新技术”,ACM SIGSOFT 软件工程笔记,卷。39,2014 年,第 1-6 页。

Ramanathan, N., A. Lal, and R. Parmar, “State of the Art in Software Quality Assurance,” ACM SIGSOFT Software Engineering Notes, vol. 39, 2014, pp. 1–6.

[NAS07]

[NAS07]

NASA,“软件风险清单,表格 LeR-F0510.051”,2007 年 3 月,可从 https://www.scribd.com/document/250436/Software-Risk-Checklist-Department-of-Defense-

NASA-USA 获取。

NASA, “Software Risk Checklist, Form LeR-F0510.051,” March 2007, available at https://www.scribd.com/document/250436/Software-Risk-Checklist-Department-of-Defense-

NASA-USA.

[Nat15]

[Nat15]

National Instruments,“创建功能原型的 7 个步骤”,2015 年 11 月,可访问 http://www.ni.com/white-paper/10590/en/。

National Instruments, “7 Steps in Creating a Functional Prototype,” November 2015, available at http://www.ni.com/white-paper/10590/en/.

[内14]

[Nei14]

Neil, T.,移动设计模式库:智能手机应用程序的 UI 模式,第二版,O'Reilly Media,2014 年。

Neil, T., Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps, 2nd ed., O’Reilly Media, 2014.

[内93]

[Nei93]

尼尔森,J.,可用性工程。摩根考夫曼出版公司,1993。

Nielsen, J., Usability Engineering. Morgan Kaufmann Publishers Inc., 1993.

[网18]

[Net18]

Neto, F. 等人,“通过基于相似性的测试用例选择来改进持续集成”,第 13 届软件测试自动化国际研讨会 (AST '18), ACM,纽约,2018 年,第 39 页 – 45.

Neto, F., et al., “Improving Continuous Integration with Similarity-Based Test Case Selection,” Proceedings 13th International Workshop on Automation of Software Test (AST ’18), ACM, New York, NY, 2018, pp. 39–45.

[聂00]

[Nie00]

Nielsen, J.,设计 Web 可用性, New Riders Publishing,2000 年。

Nielsen, J., Designing Web Usability, New Riders Publishing, 2000.

[聂10]

[Nie10]

Nielsen, D.,“成功构建软件原型”,2010 年 7 月,http://www.nuwavetech.com/it-project-blog/bid/43839/successively-building-a-software-prototype(1 月 16 日下载, 2018)。

Nielsen, D., “Successfully Building a Software Prototype,” July 2010, http://www.nuwavetech.com/it-project-blog/bid/43839/successfully-building-a-software-prototype (downloaded January 16, 2018).

[聂13]

[Nie13]

Nielsen, L., 《人机交互百科全书》中的“角色” ,第 2 版,M. Soegaard(主编),交互设计基金会,2013 年。

Nielsen, L., “Personas,” in The Encyclopedia of Human-Computer Interaction, 2nd ed., M. Soegaard (ed.), The Interaction Design Foundation, 2013.

[聂94]

[Nie94]

Nielsen, J. 和 J. Levy,“衡量可用性:偏好与性能”,CACM,卷。37、没有。4,1994 年 4 月,第 65-75 页。

Nielsen, J., and J. Levy, “Measuring Usability: Preference vs. Performance,” CACM, vol. 37, no. 4, April 1994, pp. 65–75.

[聂96]

[Nie96]

Nielsen, J. 和 A. Wagner,“WWW 用户界面设计”,CHI '96 会议论文集。关于计算系统中的人为因素, ACM Press,1996 年,第 330–331 页。

Nielsen, J., and A. Wagner, “User Interface Design for the WWW,” Proceedings CHI ’96 Conf. on Human Factors in Computing Systems, ACM Press, 1996, pp. 330–331.

[Nor13]

[Nor13]

Norman,DA,《日常事物的设计》,修订扩展版,Basic Books, Inc.,2013 年。

Norman, D. A., The Design of Everyday Things, Revised Expanded Edition, Basic Books, Inc., 2013.

[诺70]

[Nor70]

Norden, P.,“项目管理的有用工具”,《生产管理》, MK Starr(编辑),企鹅图书,1970 年。

Norden, P., “Useful Tools for Project Management,” in Management of Production, M. K. Starr (ed.), Penguin Books, 1970.

[Nor88]

[Nor88]

Norman, D.,《日常事物的设计》, Doubleday,1988 年。

Norman, D., The Design of Everyday Things, Doubleday, 1988.

[11月5日]

[Nov05]

Novotny, O.,“面向对象开发的下一代工具”,《建筑杂志》, 2005 年 1 月,可从 http://msdn2.microsoft.com/en-us/library/aa480062.aspx 获取。

Novotny, O., “Next Generation Tools for Object-Oriented Development,” The Architecture Journal, January 2005, available at http://msdn2.microsoft.com/en-us/library/aa480062.aspx.

[数字18]

[Num18]

NumFOCUS,“Python 数据分析库”,2018 年。摘自 pandas:http://pandas.pydata.org/。

NumFOCUS, “Python Data Analysis Library,” 2018. Retrieved from pandas: http://pandas.pydata.org/.

[修女11]

[Nun11]

第653页Nunes, N.、L. Constantine 和 R. Kazman,“iUCP:通过增强的用例点估算交互式软件项目规模”,IEEE Software,卷。28、没有。4,2011 年 7 月至 8 月,第 64-73 页。

Page 653Nunes, N., L. Constantine, and R. Kazman, “iUCP: Estimating Interactive Software Project Size with Enhanced Use Case Points,” IEEE Software, vol. 28, no. 4, July–August 2011, pp. 64–73.

[修女17]

[Nun17]

Nunez-Iglesias, J.、S. Walt 和 H. Dashnow,优雅的 SciPy, O'Reilly Media,2017 年。

Nunez-Iglesias, J., S. Walt, and H. Dashnow, Elegant SciPy, O’Reilly Media, 2017.

[尼格11]

[Nyg11]

Nygard, M.,“记录架构决策”,2011 年,可访问 http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions。

Nygard, M., “Documenting Architecture Decisions,” 2011, available at http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions.

[关闭02]

[Off02]

Offutt, J.,“Web 软件应用程序的质量属性”,IEEE Software, 2002 年 3 月至 4 月,第 25-32 页。

Offutt, J., “Quality Attributes of Web Software Applications,” IEEE Software, March–April 2002, pp. 25–32.

[奥尔斯99]

[Ols99]

Olsina, L. 等人,“指定网站的质量特征和属性”,第一届 ICSE Web 工程研讨会论文集, ACM,洛杉矶,1999 年 5 月。

Olsina, L., et al., “Specifying Quality Characteristics and Attributes for Web Sites,” Proceedings 1st ICSE Workshop on Web Engineering, ACM, Los Angeles, May 1999.

[天啊03]

[OMG03]

对象管理组,OMG 统一建模语言规范,版本 1.5,2003 年 3 月,可从 www.rational.com/uml/resources/documentation/ 获取。

Object Management Group, OMG Unified Modeling Language Specification, version 1.5, March 2003, available at www.rational.com/uml/resources/documentation/.

[奥斯17]

[Oth17]

Othmane, BL 等人,“是时候解决软件安全问题了:预测模型和影响因素”,数据科学工程,卷。2、没有。2,2017 年,第 107-124 页。

Othmane, B. L., et al., “Time for Addressing Software Security Issues: Prediction Models and Impacting Factors,” Data Science Engineering, vol. 2, no. 2, 2017, pp. 107–124.

[Osb90]

[Osb90]

Osborne、WM 和 EJ Chikofsky,“解决维护难题”,IEEE 软件, 1990 年 1 月,第 10-11 页。

Osborne, W. M., and E. J. Chikofsky, “Fitting Pieces to the Maintenance Puzzle,” IEEE Software, January 1990, pp. 10–11.

[OSO12]

[OSO12]

OpenSource.org,2012 年,可访问 www.opensource.org/。

OpenSource.org, 2012, available at www.opensource.org/.

[欧恩17]

[Oun17]

Ouni, A.、M. Kessentini 和 M. Cinneide,“更多:引入设计模式和修复代码味道的多目标重构推荐方法”,《软件杂志:进化与过程》, 2017 年,可在 https:// doi.org/10.1002/smr.1843。

Ouni, A., M. Kessentini, and M. Cinneide, “MORE: A Multi-Objective Refactoring Recommendation Approach to Introducing Design Patterns and Fixing Code Smells,” Journal of Software: Evolution and Process, 2017, available at https://doi.org/10.1002/smr.1843.

[OWA16]

[OWA16]

“开放 Web 应用程序安全项目 — 缓冲区溢出”,2016 年,可在 https://www.owasp.org/index.php/Buffer_Overflow 获取。

“Open Web Application Security Project—Buffer Overflow,” 2016, available at https://www.owasp.org/index.php/Buffer_Overflow.

[OWA18]

[OWA18]

“开放 Web 应用程序安全项目 — 攻击面备忘单”,2018 年,可在 https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Attack_Surface_

Analysis_Cheat_Sheet.md 上获取。

“Open Web Application Security Project—Attack Surface Cheat Sheet,” 2018, available at https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Attack_Surface_

Analysis_Cheat_Sheet.md.

[垫18]

[Pad18]

Padhy, N. 等人,“软件可重用性指标估计:算法、模型和优化技术”,计算机和电气工程,卷。69,2018 年 7 月,第 653-668 页。

Padhy, N., et al., “Software Reusability Metrics Estimation: Algorithms, Models and Optimization Techniques,” Computers and Electrical Engineering, vol. 69, July 2018, pp. 653–668.

[第85页]

[Pag85]

Page-Jones, M.,《实用项目管理》, Dorset House,1985 年。

Page-Jones, M., Practical Project Management, Dorset House, 1985.

[第11段]

[Par11]

Pardo, C. 等人,“协调质量保证流程和产品特性”,IEEE 计算机, 2011 年 6 月,第 94-96 页。

Pardo, C., et al., “Harmonizing Quality Assurance Processes and Product Characteristics,” IEEE Computer, June 2011, pp. 94–96.

[15杆]

[Par15]

Parunak, H. 和 S. Brueckner,“自组织系统的软件工程”,知识工程评论,卷。30,没有。4,2015 年 9 月,第 419-434 页。

Parunak, H., and S. Brueckner, “Software Engineering for Self-Organizing Systems,” The Knowledge Engineering Review, vol. 30, no. 4, September 2015, pp. 419–434.

[72段]

[Par72]

Parnas, D.,“关于将系统分解为模块的标准”,CACM,卷。14、没有。1,1972 年 4 月,第 221-227 页。

Parnas, D., “On Criteria to Be Used in Decomposing Systems into Modules,” CACM, vol. 14, no. 1, April 1972, pp. 221–227.

[96b]

[Par96b]

Park, RE、WB Goethert 和 WA Florac,目标驱动软件测量指南, CMU/SEI-96-BH-002,卡内基梅隆大学软件工程学院,1996 年 8 月。

Park, R. E., W. B. Goethert, and W. A. Florac, Goal Driven Software Measurement—A Guidebook, CMU/SEI-96-BH-002, Software Engineering Institute, Carnegie Mellon University, August 1996.

[帕斯10]

[Pas10]

Passos, L. 等人,“静态架构一致性检查:说明性概述”,IEEE 软件,卷。27、没有。5,2010 年 9 月至 10 月,第 82-89 页。

Passos, L., et al., “Static Architecture-Conformance Checking: An Illustrative Overview,” IEEE Software, vol. 27, no. 5, September–October 2010, pp. 82–89.

[保罗94]

[Pau94]

Paulish, D. 和 A. Carleton,“软件过程改进测量案例研究”,计算机,卷。27、没有。9,1994 年 9 月,第 50-57 页。

Paulish, D., and A. Carleton, “Case Studies of Software Process Improvement Measurement,” Computer, vol. 27, no. 9, September 1994, pp. 50–57.

[Ped15]

[Ped15]

Pedreira, O. 等人,“软件工程中的游戏化 - 系统映射”,信息和软件技术,卷。57,2015 年,第 157-168 页。

Pedreira, O., et al., “Gamification in Software Engineering—A Systematic Mapping,” Information and Software Technology, vol. 57, 2015, pp. 157–168.

[每74]

[Per74]

Persig, R.,《禅与摩托车维修艺术》, Bantam Books,1974 年。

Persig, R., Zen and the Art of Motorcycle Maintenance, Bantam Books, 1974.

[宠物18]

[Pet18]

Petke, J. 等人,“软件的遗传改进:综合调查”,发表于IEEE Transactions on Evolutionary Computation,卷。22、没有。3,2018 年 6 月,第 415-432 页。

Petke, J., et al., “Genetic Improvement of Software: A Comprehensive Survey,” in IEEE Transactions on Evolutionary Computation, vol. 22, no. 3, June 2018, pp. 415–432.

[皮尤18]

[Pew18]

PEW 研究中心,“移动情况说明书”,2018 年,可访问 http://www.pewinternet.org/fact-sheet/mobile/。

PEW Research Center, “Mobile Fact Sheet,” 2018, available at http://www.pewinternet.org/fact-sheet/mobile/.

[Φ02]

[Phi02]

Phillips, M.,“CMMI V1.1 教程”,2002 年 4 月,可从 www.sei.cmu.edu/cmmi/ 获取。

Phillips, M., “CMMI V1.1 Tutorial,” April 2002, available at www.sei.cmu.edu/cmmi/.

【坑18】

[Pit18]

Pitoura, E. 等人,“在线信息中的偏差测量”,SIGMOD,卷。46,没有。4,2018 年 2 月,第 16-21 页。

Pitoura, E., et al., “On Measuring Bias in Online Information,” SIGMOD, vol. 46, no. 4, February 2018, pp. 16–21.

[波尔45]

[Pol45]

Polya, G.,如何解决它,普林斯顿大学出版社,1945 年。

Polya, G., How to Solve It, Princeton University Press, 1945.

[流行08]

[Pop08]

Popcorn, F.,Faith Popcorn 的大脑储备, 2008 年,可在 www.faithpopcorn.com/ 上获取。

Popcorn, F., Faith Popcorn’s Brain Reserve, 2008, available at www.faithpopcorn.com/.

[18]

[Por18]

Port, D. 和 B. Taber,“关键软件战略维护的可行分析:行业经验报告”,IEEE Software,卷。35,没有。1,2018 年 1 月至 2 月,第 58-63 页。

Port, D., and B. Taber, “Actionable Analytics for Strategic Maintenance of Critical Software: An Industry Experience Report,” IEEE Software, vol. 35, no. 1, January–February 2018, pp. 58–63.

[上一篇05]

[Pre05]

Pressman, R.,“适应性过程模型,版本 2.0”,RS Pressman & Associates,2005 年,可从 www.rspa.com/apm/index.html 获取。

Pressman, R., “Adaptable Process Model, Version 2.0,” R. S. Pressman & Associates, 2005, available at www.rspa.com/apm/index.html.

[上一篇08]

[Pre08]

第654页Pressman, R. 和 D. Lowe,网络工程:从业者的方法, McGraw-Hill,2008 年。

Page 654Pressman, R., and D. Lowe, Web Engineering: A Practitioner’s Approach, McGraw-Hill, 2008.

[88前]

[Pre88]

Pressman, R.,《让软件工程发生》, Prentice Hall,1988 年。

Pressman, R., Making Software Engineering Happen, Prentice Hall, 1988.

[预94]

[Pre94]

Premerlani, W. 和 M. Blaha,“关系数据库逆向工程方法”,CACM,卷。37、没有。5,1994 年 5 月,第 42-49 页。

Premerlani, W., and M. Blaha, “An Approach for Reverse Engineering of Relational Databases,” CACM, vol. 37, no. 5, May 1994, pp. 42–49.

[10年级]

[Pri10]

Prince, B.,“10 个最危险的 Web 应用程序安全缺陷”,eWeek.com, 2010 年 4 月 19 日,网址为 https://www.eweek.com/security/10-most-dangerous-web-app-security-风险。

Prince, B., “10 Most Dangerous Web App Security Flaws,” eWeek.com, April 19, 2010, available at https://www.eweek.com/security/10-most-dangerous-web-app-security-risks.

[双关语17]

[Pun17]

Punchoojit, L. 和 N. Hongwarittorrn,“移动用户界面设计模式的可用性研究:系统文献综述”,人机交互进展,可访问 https://www.hindawi.com/journals/ahci/2017 /6787504/

Punchoojit, L., and N. Hongwarittorrn, “Usability Studies on Mobile User Interface Design Patterns: A Systematic Literature Review,” Advances in Human-Computer Interaction, available at https://www.hindawi.com/journals/ahci/2017/6787504/

[放置78]

[Put78]

Putnam, L.,“宏观软件规模调整和估计问题的通用经验解决方案”,IEEE 软件工程汇刊,卷。SE-4,没有。4,1978 年 7 月,第 345-361 页。

Putnam, L., “A General Empirical Solution to the Macro Software Sizing and Estimation Problem,” IEEE Transactions on Software Engineering, vol. SE-4, no. 4, July 1978, pp. 345–361.

[放置92]

[Put92]

Putnam, L. 和 W. Myers,《卓越衡量标准》, Yourdon Press,1992 年。

Putnam, L., and W. Myers, Measures for Excellence, Yourdon Press, 1992.

[Pyz14]

[Pyz14]

Pyzdek, T. 和 P. Keller,《六西格码手册》,第四版,McGraw-Hill,2014 年。

Pyzdek, T., and P. Keller, The Six Sigma Handbook, 4th ed., McGraw-Hill, 2014.

[拉德02]

[Rad02]

Radice, R.,高质量低成本软件检查, Paradoxicon Publishing,2002 年。

Radice, R., High-Quality Low Cost Software Inspections, Paradoxicon Publishing, 2002.

[拉吉14]

[Raj14]

Rajagoplan, S.,“原始开发模型神话的回顾”,国际软件工程与应用杂志,卷。5、没有。6,2014 年 11 月,第 103-111 页。

Rajagoplan, S., “Review of the Myths on Original Development Model,” International Journal of Software Engineering and Applications, vol. 5, no. 6, November 2014, pp. 103–111.

[射线12]

[Ray12]

Raymond P.、L. Buse 和 T. Zimmermann。“软件开发分析的信息需求”,第 34 届国际软件工程会议论文集 (ICSE '12), IEEE Press,皮斯卡塔韦,新泽西州,2012 年,第 987-996 页。

Raymond P., L. Buse, and T. Zimmermann. “Information Needs for Software Development Analytics,” Proceedings 34th International Conference on Software Engineering (ICSE ’12), IEEE Press, Piscataway, NJ, 2012, pp. 987–996.

[雷99]

[Ree99]

Reel, J.,“软件项目中的关键成功因素”,IEEE Software, 1999 年 5 月,第 18-23 页。

Reel, J., “Critical Success Factors in Software Projects,” IEEE Software, May 1999, pp. 18–23.

[雷姆14]

[Rem14]

Rempel, P. 等人,“注意差距:评估软件可追溯性与相关指南的一致性”,第 36 届国际软件工程会议记录 (ICSE 2014)。ACM,纽约,2014 年,第 943–954 页。

Rempel, P., et al., “Mind the Gap: Assessing the Conformance of Software Traceability to Relevant Guidelines,” Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, 2014, pp. 943–954.

[雷乌12]

[Reu12]

Reuveni, D.,“众包为应用程序测试困境提供了答案”,2012 年,可访问 https://www.ecnmag.com/article/2010/02/crowdcommerce-provides-answer-app-testing-dilemma。

Reuveni, D., “Crowdsourcing Provides Answer to App Testing Dilemma,” 2012, available at https://www.ecnmag.com/article/2010/02/crowdsourcing-provides-answer-app-testing-dilemma.

[瑞克04]

[Ric04]

Rico, D.,《软件流程改进的投资回报率》, J. Ross Publishing,2004 年,可从 http://davidfrico.com/rico03a.pdf 获取。

Rico, D., ROI of Software Process Improvement, J. Ross Publishing, 2004, available at http://davidfrico.com/rico03a.pdf.

[抢10]

[Rob10]

Robinson, W.,“全面需求监控路线图”,IEEE 计算机,卷。43,没有。5,2010 年 5 月,第 64-72 页。

Robinson, W., “A Roadmap for Comprehensive Requirements Monitoring,” IEEE Computer, vol. 43, no. 5, May 2010, pp. 64–72.

[杆16]

[Rod16]

Rodríguez, A.、F. Ortega 和 R. Concepción,“IT 项目风险评估方法”,专家系统与应用,卷。45,2016 年,第 273-285 页。

Rodríguez, A., F. Ortega, and R. Concepción, “A Method for the Evaluation of Risk in IT Projects,” Expert Systems with Applications, vol. 45, 2016, pp. 273–285.

[杆17]

[Rod17]

Rodríguez, P. 等人,“软件密集型产品和服务的持续部署:系统映射研究”,系统与软件杂志,卷。123,2017 年,第 263-291 页。

Rodríguez, P., et al., “Continuous Deployment of Software Intensive Products and Services: A Systematic Mapping Study,” Journal of Systems and Software, vol. 123, 2017, pp. 263–291.

[罗德98]

[Rod98]

Rodden, T. 等人,“利用移动系统 HCI 设计中的上下文”,移动设备人机交互研讨会论文集, 1998 年。

Rodden, T., et al., “Exploiting Context in HCI Design for Mobile Systems,” Proceedings of Workshop on Human Computer Interaction with Mobile Devices, 1998.

[Roo09]

[Roo09]

Rooksby, J. 等人,“野外测试:现实世界实践的社会和组织维度”,计算机支持工作杂志,卷。18、没有。5-6,2009 年 12 月,第 559-580 页。

Rooksby, J., et al., “Testing in the Wild: The Social and Organizational Dimensions of Real World Practice,” Journal of Computer Supported Work, vol. 18, no. 5–6, December 2009, pp. 559–580.

[罗斯17]

[Ros17]

Rosa, W. 和 C. Wallshein,“合同成本提案评估的软件工作量估算模型”,2017 年 ICEAA 专业发展和培训研讨会论文集, 2017 年 6 月,第 1-8 页。

Rosa, W., and C. Wallshein, “Software Effort Estimation Models for Contract Cost Proposal Evaluation,” Proceedings 2017 ICEAA Professional Development & Training Workshop, June 2017, pp. 1–8.

[罗斯75]

[Ros75]

Ross, D.、J. Goodenough 和 C. Irvine,“软件工程:过程、原则和目标”,IEEE 计算机,卷。8、不。5、1975 年 5 月。

Ross, D., J. Goodenough, and C. Irvine, “Software Engineering: Process, Principles and Goals,” IEEE Computer, vol. 8, no. 5, May 1975.

[罗02]

[Rot02]

Roth, J.,“移动群件开发人员面临的七大挑战”,移动自组织协作计算机人机交互研讨会论文集, 2002 年。

Roth, J., “Seven Challenges for Developers of Mobile Groupware,” Proceedings of Computer Human Interaction Workshop on Mobile Ad Hoc Collaboration, 2002.

[柔02]

[Rou02]

Rout, T.(项目经理),SPICE:软件过程评估 - 第 1 部分:概念和介绍指南, 2002 年,可从 http://www.noginfo.com.br/arquivos/SPICE.pdf 下载。

Rout, T. (project manager), SPICE: Software Process Assessment—Part 1: Concepts and Introductory Guide, 2002, downloadable at http://www.noginfo.com.br/arquivos/SPICE.pdf.

[罗伊70]

[Roy70]

Royce, W.,“管理大型软件系统的开发:概念和技术”,WESCON 会议记录, 1970 年 8 月。

Royce, W., “Managing the Development of Large Software Systems: Concepts and Techniques,” Proceedings WESCON, August 1970.

[罗兹11]

[Roz11]

Rozanski, N. 和 E. Woods,软件系统架构,第二版,Addison-Wesley,2011 年。

Rozanski, N., and E. Woods, Software Systems Architecture, 2nd ed., Addison-Wesley, 2011.

[瑞亚11]

[Rya11]

Ryan, T.,质量改进的统计方法, Wiley,2011 年。

Ryan, T., Statistical Methods for Quality Improvement, Wiley, 2011.

[桑17]

[San17]

Sancetta, G. 等人,“风险模式、结构特征和组织配置”,战略变革, 2017 年,网址为 https://doi.org/10.1002/jsc.2138。

Sancetta, G., et al., “Risk Patterns, Structural Characteristics, and Organizational Configurations,” Strategic Change, 2017, available at https://doi.org/10.1002/jsc.2138.

[场景02]

[Sce02]

Sceppa, D.,Microsoft ADO.NET,微软出版社,2002 年。

Sceppa, D., Microsoft ADO.NET, Microsoft Press, 2002.

[斯卡15]

[Sca15]

Scandariato, R.、K. Wuyts 和 W. Joosen,“Microsoft 威胁建模技术的描述性研究”,需求工程,卷。20、没有。2,2015 年 6 月,第 163-180 页。

Scandariato, R., K. Wuyts, and W. Joosen, “A Descriptive Study of Microsoft’s Threat Modeling Technique,” Requirements Engineering, vol. 20, no. 2, June 2015, pp. 163–180.

[Sch01a]

[Sch01a]

第655页Schneider, G. 和 J. Winters,应用用例,第二版,Que,2001 年。

Page 655Schneider, G., and J. Winters, Applying Use Cases, 2nd ed., Que, 2001.

[Sch01b]

[Sch01b]

Schwaber, K. 和 M. Beedle,使用 SCRUM 进行敏捷软件开发, Prentice Hall,2001 年。

Schwaber, K., and M. Beedle, Agile Software Development with SCRUM, Prentice Hall, 2001.

[Sch06]

[Sch06]

Schmidt, D.,“模型驱动工程”,IEEE 计算机,卷。39,没有。2,2006 年 2 月,第 25-31 页。

Schmidt, D., “Model-Driven Engineering,” IEEE Computer, vol. 39, no. 2, February 2006, pp. 25–31.

[Sch09]

[Sch09]

Schumacher, R.(主编),《全球用户研究手册》, Morgan-Kaufmann,2009 年。

Schumacher, R. (ed.), Handbook of Global User Research, Morgan-Kaufmann, 2009.

[表11]

[Sch11]

Schilit, B.,“移动计算:展望未来”,IEEE 计算机,卷。44,没有。5,2011 年 5 月,第 28-29 页。

Schilit, B., “Mobile Computing: Looking to the Future,” IEEE Computer, vol. 44, no. 5, May 2011, pp. 28–29.

[表15]

[Sch15]

Schell, M. 和 J. O'Brien,《传达用户体验愿景:阻碍创意的 13 种反模式》, Morgan Kaufman,2015 年。

Schell, M., and J. O’Brien, Communicating the UX Vision: 13 Anti-Patterns That Block Ideas, Morgan Kaufman, 2015.

[Sch98]

[Sch98]

Schneider, G. 和 J. Winters,应用用例, Addison-Wesley,1998。

Schneider, G., and J. Winters, Applying Use Cases, Addison-Wesley, 1998.

[Sch99]

[Sch99]

Schneidewind, N.,“使用可靠性、风险和测试指标测量和评估维护过程”,IEEE Transactions, SE,卷。25、没有。6,1999 年 11 月至 12 月,

第 768-781 页。

Schneidewind, N., “Measuring and Evaluating Maintenance Process Using Reliability, Risk, and Test Metrics,” IEEE Transactions, SE, vol. 25, no. 6, November–December 1999,

pp. 768–781.

[科学18]

[Sci18]

SciPy 开发人员,SciPy 库, 2018 年,可在 https://scipy.org/scipylib/index.html 获取。

SciPy Developers, SciPy Library, 2018, available at https://scipy.org/scipylib/index.html.

[SEI02]

[SEI02]

SEI,“衡量程序可维护性的可维护性指数技术”,2002 年。

SEI, “Maintainability Index Technique for Measuring Program Maintainability,” 2002.

[SEI08]

[SEI08]

软件工程学院,“理想模型”,2008 年,可访问 https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=20208。

Software Engineering Institute, “The Ideal Model,” 2008, available at https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=20208.

[15号丝氨酸]

[Ser15]

Serrador, P. 和 J. Pinto,“敏捷有效吗?——敏捷项目成功的定量分析”,《国际项目管理杂志》,卷。33、没有。5,2015 年,第 1040–1051 页。

Serrador, P., and J. Pinto, “Does Agile Work?—A Quantitative Analysis of Agile Project Success,” International Journal of Project Management, vol. 33, no. 5, 2015, pp. 1040–1051.

[莎05]

[Sha05]

Shalloway, A. 和 J. Trott,《设计模式解释》,第 2 版,Addison-Wesley,2005 年。

Shalloway, A., and J. Trott, Design Patterns Explained, 2nd ed., Addison-Wesley, 2005.

[沙09]

[Sha09]

Shaw, M.,“软件工程学科的持续前景”,IEEE Software,卷。26、没有。8,2009 年 11 月至 12 月,第 64-67 页。

Shaw, M., “Continuing Prospects for an Engineering Discipline of Software,” IEEE Software, vol. 26, no. 8, November–December 2009, pp. 64–67.

[沙15]

[Sha15]

Shaw, M. 和 D. Garla,软件架构: 新兴学科的视角, Pearson,2015 年。

Shaw, M., and D. Garla, Software Architecture: Perspectives on an Emerging Discipline, Pearson, 2015.

[沙17]

[Sha17]

Sharma, S. 和 B. Coyne,DevOps for Dummies,第 3 版,Wiley,2017 年。

Sharma, S., and B. Coyne, DevOps for Dummies, 3rd ed., Wiley, 2017.

[申09]

[Shn09]

Shneiderman, B. 等人,设计用户界面,第 5 版,Addison-Wesley,2009 年。

Shneiderman, B., et al., Designing the User Interface, 5th ed., Addison-Wesley, 2009.

[申16]

[Shn16]

Shneiderman, B. 等人,设计用户界面:有效人机交互策略,第 6 版,Pearson,2016 年。

Shneiderman, B., et al., Designing the User Interface: Strategies for Effective Human-Computer Interaction, 6th ed., Pearson, 2016.

[笑14]

[Sho14]

Shostack, A.,威胁建模:安全设计。约翰·威利父子公司,2014 年。

Shostack, A., Threat Modeling: Designing for Security. John Wiley & Sons, 2014.

[舒12]

[Shu12]

Shull, F.,“触手可及的设计世界:移动用户界面概览”,IEEE Software,卷。29、没有。4,2012 年 7 月至 8 月,第 4-7 页。

Shull, F., “Designing a World at Your Fingertips: A Look at Mobile User Interfaces,” IEEE Software, vol. 29, no. 4, July–August 2012, pp. 4–7.

[舒13]

[Shu13]

Shunn, A. 等人,《安全解决方案的优势》,卡内基梅隆大学软件工程学院,2013 年,可访问 http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=77878。

Shunn, A., et al., Strengths in Security Solutions, Software Engineering Institute, Carnegie Mellon University, 2013, available at http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=77878.

[舒16]

[Shu16]

Shull, F.,《威胁建模方法评估》,卡内基梅隆大学软件工程研究所,2016 年,可访问 http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=474197。

Shull, F., Evaluation of Threat Modeling Methodologies, Software Engineering Institute, Carnegie Mellon University, 2016, available at http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=474197.

[罪00]

[Sin00]

Sindre, G. 和 A. Opdahl,“通过误用案例引发安全要求”,第 37 届面向对象语言和系统技术国际会议 (TOOLS-37'00),纽约,纽约:IEEE Press,2000 年,第 120–131 页。

Sindre, G., and A. Opdahl, “Eliciting Security Requirements by Misuse Cases,” Proceedings 37th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-37’00), New York, NY: IEEE Press, 2000, pp. 120–131.

[罪01]

[Sin01]

Sindre, G. 和 A. Opdahl,“误用案例描述模板”,第七届国际需求工程研讨会:软件质量基础, 2001 年,可在 http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.9.8190。

Sindre, G., and A. Opdahl, “Templates for Misuse Case Description,” Seventh International Workshop on Requirements Engineering: Foundation for Software Quality, 2001, available at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.8190.

[SLA12]

[Sla12]

Slattery, K.,“研究显示本地化测试的重要性”,2012 年。相关文章可在 https://www.welocalize.com/6-reasons-localization-qa-testing-important/ 上找到。

Slattery, K., “Study Shows the Importance of Localization Testing,” 2012. A related article can be found at https://www.welocalize.com/6-reasons-localization-qa-testing-important/.

[斯莫08]

[Smo08]

Smolander, K. 等人,“软件架构:蓝图、文献、语言还是决策?” 欧洲信息系统杂志,卷。17,2008 年,第 575–588 页。

Smolander, K., et al., “Software Architectures: Blueprint, Literature, Language, or Decision?” European Journal of Information Systems, vol. 17, 2008, pp. 575–588.

[斯奈18]

[Sne18]

Snee, R. 和 R. Hoerl,《领先的六西格码》,第二版,培生,2018 年。

Snee, R., and R. Hoerl, Leading Six Sigma, 2nd ed., Pearson, 2018.

[斯奈95]

[Sne95]

Sneed, H.,“规划遗留系统的重新设计”,IEEE Software, 1995 年 1 月,第 24-25 页。

Sneed, H., “Planning the Reengineering of Legacy Systems,” IEEE Software, January 1995, pp. 24–25.

[索阿10]

[Soa10]

Soares, G. 等人,“让程序重构更安全”,IEEE 软件,卷。37、没有。4,2010 年 7 月至 8 月,第 52-57 页。

Soares, G., et al., “Making Program Refactoring Safer,” IEEE Software, vol. 37, no. 4, July–August 2010, pp. 52–57.

[索阿11]

[Soa11]

SOASTA,白皮书:“移动应用程序性能测试的五种策略”,2011 年,可从 http://hosteddocs.ittoolbox.com/whitepapersoastamobile.pdf 获取。

SOASTA, White Paper: “Five Strategies for Performance Testing Mobile Applications,” 2011, available at http://hosteddocs.ittoolbox.com/whitepapersoastamobile.pdf.

[索姆97]

[Som97]

Somerville, I. 和 P. Sawyer,需求工程, Wiley,1997 年。

Somerville, I., and P. Sawyer, Requirements Engineering, Wiley, 1997.

[索姆05]

[Som05]

Somerville, I.,“集成需求工程:教程”,IEEE Software,卷。22、没有。1,2005 年 1 月至 2 月,第 16-23 页。

Somerville, I., “Integrating Requirements Engineering: A Tutorial,” IEEE Software, vol. 22, no. 1, January–February 2005, pp. 16–23.

[搜08]

[Sou08]

第656页de Sousa, C. 和 D. Redmiles,“软件开发人员依赖关系和变更管理的实证研究”,ICSE 会议记录, 2008 年 5 月,可在 www.ics.uci.edu/~redmiles/publications/C078-deSR08 上获取。 pdf。

Page 656de Sousa, C., and D. Redmiles, “An Empirical Study of Software Developer’s Management of Dependencies and Changes,” ICSE Proceedings, May 2008, available at www.ics.uci.edu/~redmiles/publications/C078-deSR08.pdf.

[水疗11]

[Spa11]

Spagnolli, B. 等人,“旅途中的生态反馈:激发能源意识”,IEEE 计算机,卷。44,没有。5,2011 年 5 月,第 38-45 页。

Spagnolli, B., et al., “Eco-Feedback on the Go: Motivating Energy Awareness,” IEEE Computer, vol. 44, no. 5, May 2011, pp. 38–45.

[SPI99]

[SPI99]

“SPICE:软件过程评估,第 1 部分:概念和简介”,1.0 版,ISO/IEC JTC1,1999 年。

“SPICE: Software Process Assessment, Part 1: Concepts and Introduction,” Version 1.0, ISO/IEC JTC1, 1999.

[SSO08]

[SSO08]

Software-Supportability.org,2008 年,可在 www.software-supportability.org/ 上获取。

Software-Supportability.org, 2008, available at www.software-supportability.org/.

[10]

[Ste10]

Stephens, M. 和 D. Rosenberg,设计驱动测试, Apress,2010 年。

Stephens, M., and D. Rosenberg, Design Driven Testing, Apress, 2010.

[16]

[Ste16]

Steed, S. 等人,“使用消费者虚拟现实设备进行存在和体现的‘野外’实验”,IEEE 可视化和计算机图形学汇刊,卷。22、没有。4,2016 年 4 月,第 1406-1414 页。

Steed, S., et al., “An ‘In the Wild’ Experiment on Presence and Embodiment Using Consumer Virtual Reality Equipment,” IEEE Transactions on Visualization and Computer Graphics, vol. 22, no. 4, April 2016, pp. 1406–1414.

[18]

[Ste18]

Steffens, A.、H. Lichter 和 J. Döring,“设计下一代连续软件交付系统:概念和架构”,第四届快速连续软件工程国际研讨会 (RCoSE '18), ACM,纽约,纽约,2018 年,第 1-7 页。

Steffens, A., H. Lichter, and J. Döring, “Designing a Next-Generation Continuous Software Delivery System: Concepts and Architecture,” Proceedings 4th International Workshop on Rapid Continuous Software Engineering (RCoSE ’18), ACM, New York, NY, 2018, pp. 1–7.

[Ste74]

[Ste74]

Stevens, W.、G. Myers 和 L. Constantine,“结构化设计”,IBM Systems Journal,卷。13、没有。2,1974 年,第 115-139 页。

Stevens, W., G. Myers, and L. Constantine, “Structured Design,” IBM Systems Journal, vol. 13, no. 2, 1974, pp. 115–139.

[斯托05]

[Sto05]

Stone, D. 等人,用户界面设计和评估, Morgan Kaufman,2005 年。

Stone, D., et al., User Interface Design and Evaluation, Morgan Kaufman, 2005.

[苏尔11]

[Sul11]

Sullivam, B. 和 V. Liu,Web 应用程序安全,初学者指南, McGraw-Hill,2011 年。

Sullivam, B., and V. Liu, Web Application Security, A Beginner’s Guide, McGraw-Hill, 2011.

[周日15]

[Sun15]

Sun X., et al.,“我们需要软件历史存储库中的哪些信息来支持软件维护任务?基于主题模型的方法,”《计算机与信息科学》,《计算智能研究》,R. Lee(编辑),卷。566,施普林格,2015。

Sun X., et al., “What Information in Software Historical Repositories Do We Need to Support Software Maintenance Tasks? An Approach Based on Topic Model,” in Computer and Information Science, Studies in Computational Intelligence, R. Lee (ed.), vol. 566, Springer, 2015.

[瑞典14]

[SWE14]

软件工程知识体系, 2014 年第 3 版,可在 https://www.computer.org/web/swebok(2018 年 12 月 9 日访问)获取。

Software Engineering Body of Knowledge, version 3, 2014, available at https://www.computer.org/web/swebok (accessed December 9, 2018).

[太12]

[Tai12]

Taivalsaari, A. 和 K. Systa,“移动内容即服务:供应商中立的移动设备云蓝图”,IEEE Software,卷。29、没有。4,2012 年 7 月至 8 月,第 28-33 页。

Taivalsaari, A., and K. Systa, “Mobile Content as a Service: A Blueprint for a Vendor-Neutral Cloud of Mobile Devices,” IEEE Software, vol. 29, no. 4, July–August 2012, pp. 28–33.

[太89]

[Tai89]

Tai, K.,“除了分支测试之外还要做什么”,ACM 软件工程笔记,卷。14、没有。2,1989 年 4 月,第 58-61 页。

Tai, K., “What to Do Beyond Branch Testing,” ACM Software Engineering Notes, vol. 14, no. 2, April 1989, pp. 58–61.

[谭01]

[Tan01]

Tandler, P.,“移动上下文感知计算的面向方面的模型驱动开发”,UbiComp 2001 会议记录:普适计算, 2001 年。

Tandler, P., “Aspect-Oriented Model-Driven Development for Mobile Context-Aware Computing,” Proceedings of UbiComp 2001: Ubiquitous Computing, 2001.

[陶17]

[Tao17]

陶浩、高杰,“浅谈构建基于云的移动测试基础设施服务系统”,《系统与软件杂志》,第 1 卷。124,2017 年,第 39-55 页。

Tao, H., and J. Gao, “On Building a Cloud-Based Mobile Testing Infrastructure Service System,” Journal of Systems and Software, vol. 124, 2017, pp. 39–55.

[泰09]

[Tay09]

Taylor, R.、N. Medvidovic 和 E. Dashofy,软件架构, Wiley,2009 年。

Taylor, R., N. Medvidovic, and E. Dashofy, Software Architecture, Wiley, 2009.

[Tho04]

[Tho04]

Thomas, J. 等人,Java 测试模式, Wiley,2004 年。

Thomas, J., et al., Java Testing Patterns, Wiley, 2004.

[Tho92]

[Tho92]

Thomsett, R.,“印第安纳琼斯风险管理学院”,美国程序员,卷。5、没有。7,1992 年 9 月,第 10-18 页。

Thomsett, R., “The Indiana Jones School of Risk Management,” American Programmer, vol. 5, no. 7, September 1992, pp. 10–18.

[抽动18]

[Tic18]

TickIT plus, 2018 年,可在 http://www.tickitplus.org/ 上获取。

TickIT plus, 2018, available at http://www.tickitplus.org/.

[Tid11]

[Tid11]

Tidwell, J.,设计界面:有效交互设计的模式,第二版,O'Reilly,2011 年。

Tidwell, J., Designing Interfaces: Patterns for Effective Interaction Design, 2nd ed., O’Reilly, 2011.

[至00]

[Til00]

Tillman, H.,“网络质量评估”,巴布森学院,2000 年 5 月 30 日,可在 http://www.dronet.org/lineeguida/ligu_pdf/evelqual.pdf 上获取。

Tillman, H., “Evaluating Quality on the Net,” Babson College, May 30, 2000, available at http://www.dronet.org/lineeguida/ligu_pdf/evelqual.pdf.

[目录18]

[Toc18]

Tonchia, S.,“项目时间管理”,工业项目管理。专业人士管理,施普林格,2018。

Tonchia, S., “Project Time Management,” in Industrial Project Management. Management for Professionals, Springer, 2018.

[托格01]

[Tog01]

Tognozzi, B.,“第一原则”,askTOG,2001 年,可访问 www.asktog.com/basics/firstPrinciples.html。

Tognozzi, B., “First Principles,” askTOG, 2001, available at www.asktog.com/basics/firstPrinciples.html.

[服务条款17]

[Tos17]

Tosun, A.、A. Bener 和 S. Akbarinasaji,“贝叶斯网络预测软件质量应用的系统文献综述”,《软件质量杂志》,卷。25、没有。1,2017 年 3 月,第 273-305 页。

Tosun, A., A. Bener, and S. Akbarinasaji, “A Systematic Literature Review on the Applications of Bayesian Networks to Predict Software Quality,” Software Quality Journal, vol. 25, no. 1, March 2017, pp. 273–305.

[三三]

[Tri03]

Trivedi, R.,专业 Web 服务安全, Wrox Press,2003 年。

Trivedi, R., Professional Web Services Security, Wrox Press, 2003.

[泰尔05]

[Tyr05]

Tyree, J. 和 A. Akerman,“架构决策:揭秘架构”,IEEE Software,卷。22、没有。2、2005 年 3 月至 4 月。

Tyree, J., and A. Akerman, “Architectural Decisions: Demystifying Architecture,” IEEE Software, vol. 22, no. 2, March–April 2005.

[大学03]

[Uni03]

Unicode, Inc.,Unicode 主页, 2003 年,可在 www.unicode.org/ 上获取。

Unicode, Inc., The Unicode Home Page, 2003, available at www.unicode.org/.

[美国87]

[USA87]

美国空军,“管理质量洞察”,AFCSP 800-14,1987 年 1 月 20 日。

U.S. Air Force, “Management Quality Insight,” AFCSP 800-14, January 20, 1987.

[乌特12]

[Ute12]

UTest,电子书:移动应用程序测试基本指南, 2012 年,可在 http://go.applause.com/rs/539-CKP-074/images/The-Essential-Guide-to-Mobile-App-Testing 获取.pdf。

UTest, E-book: Essential Guide to Mobile App Testing, 2012, available at http://go.applause.com/rs/539-CKP-074/images/The-Essential-Guide-to-Mobile-App-Testing.pdf.

[真空06]

[Vac06]

Vacca, J.,实用互联网安全, Springer,2006 年。

Vacca, J., Practical Internet Security, Springer, 2006.

[瓦克18]

[Vak18]

第657页Vakkuri, V. 和 P. Abrahamsson,“人工智能伦理的关键概念”,2018 年 IEEE 国际工程、技术与创新会议 (ICE/ITMC),斯图加特,2018 年,第 1–6 页,doi:10.1109 /ICE.2018.8436265。

Page 657Vakkuri, V., and P. Abrahamsson, “The Key Concepts of Ethics of Artificial Intelligence,” 2018 IEEE International Conference on Engineering, Technology and Innovation (ICE/ITMC), Stuttgart, 2018, pp. 1–6, doi:10.1109/ICE.2018.8436265.

[货车16]

[Van16]

VanderPlas, J.,Python 数据科学手册处理数据的基本工具, O'Reilly Media,2016 年。

VanderPlas, J., Python Data Science Handbook Essential Tools for Working with Data, O’Reilly Media, 2016.

[16]

[Vel16]

Veloso, A. 和 L. Costa,“辅助环境中数字游戏设计的启发式:将指南应用于老龄化社会”,2016 年第一届体育、健康和福祉技术与创新国际会议 (TISHW),维拉雷亚尔, 2016 年,第 1-8 页。

Veloso, A., and L. Costa, “Heuristics for Designing Digital Games in Assistive Environments: Applying the Guidelines to an Ageing Society,” 2016 1st International Conference on Technology and Innovation in Sports, Health and Wellbeing (TISHW), Vila Real, 2016, pp. 1–8.

[文03]

[Ven03]

Venners, B.,“契约设计:与 Bertrand Meyer 的对话”,Artima 开发者, 2003 年 12 月 8 日,可在 www.artima.com/intv/contracts.html 上获取。

Venners, B., “Design by Contract: A Conversation with Bertrand Meyer,” Artima Developer, December 8, 2003, available at www.artima.com/intv/contracts.html.

[维生素03]

[Vit03]

Vitharana, P.,“基于组件的软件开发的风险和挑战”,CACM,卷。46,没有。8,2003 年 8 月,第 67-72 页。

Vitharana, P., “Risks and Challenges of Component-Based Software Development,” CACM, vol. 46, no. 8, August 2003, pp. 67–72.

[维生素17]

[Vit17]

Vitharana, P.,“项目级别的缺陷传播:检查效率的结果和事后分析”,经验软件工程,卷。22、没有。1,2017 年 2 月,第 57-79 页。

Vitharana, P., “Defect Propagation at the Project-Level: Results and a Post-Hoc Analysis on Inspection Efficiency,” Empirical Software Engineering, vol. 22, no. 1, February 2017, pp. 57–79.

[美国之音12]

[Voa12]

Voas, J. 等人,“移动软件应用程序接管”,IEEE Software,卷。29、没有。4,2012 年 7 月至 8 月,第 25-27 页。

Voas, J., et al., “Mobile Software App Takeover,” IEEE Software, vol. 29, no. 4, July–August 2012, pp. 25–27.

[声音14]

[Voe14]

Voehl, F.、H. Harrington、C. Mignosa 和 R. Charron,《精益六西格码黑带手册》,生产力出版社,2014 年,https://doi.org/10.1201/b15163。

Voehl, F., H. Harrington, C. Mignosa, and R. Charron, The Lean Six Sigma Black Belt Handbook, Productivity Press, 2014, https://doi.org/10.1201/b15163.

[W3C18]

[W3C18]

W3C 网页内容可访问性指南 (WCAG 2.1), 2018 年,可在 https://www.w3.org/TR/WCAG21/ 获取。

W3C Web Content Accessibility Guidelines (WCAG 2.1), 2018, available at https://www.w3.org/TR/WCAG21/.

[沃尔12]

[Wal12]

Walker, J.,“计算机程序员在共享中学到了惨痛的教训”,《华尔街日报》,卷。260,没有。48,2012 年 8 月 27 日,第 48 页。1.

Walker, J., “Computer Programmers Learn Tough Lesson in Sharing,” The Wall Street Journal, vol. 260, no. 48, August 27, 2012, p. 1.

[战争07]

[War07]

Ward, M.,“使用 VoIP 软件构建 zBlocks——选择选择”,TMNNet,2007 年,可从 www.tmcnet.com/voip/0605/featurearticle-using-voip-software-building-blocks.htm 获取。

Ward, M., “Using VoIP Software Building zBlocks—A Look at the Choices,” TMNNet, 2007, available at www.tmcnet.com/voip/0605/featurearticle-using-voip-software-building-blocks.htm.

[曾10]

[Was10]

Wasserman, A.,“移动应用程序开发的软件工程问题”,FSE/SDP 软件工程研究未来研讨会论文集, 2010 年。

Wasserman, A., “Software Engineering Issues for Mobile Application Development,” Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research, 2010.

[网页05]

[Web05]

Weber, S.,《开源的成功》,哈佛大学出版社,2005 年。

Weber, S., The Success of Open Source, Harvard University Press, 2005.

[网络13]

[Web13]

Web 应用程序安全联盟,2013 年,可访问 http://www.webappsec.org/。

Web Application Security Consortium, 2013, available at http://www.webappsec.org/.

[Wee11]

[Wee11]

Weevers, I.,“设计高性能移动用户体验的七项指南”,Smashing 杂志, 2011 年 7 月 18 日,网址:http://uxdesign.smashingmagazine.com/2011/07/18/seven-guidelines-for-designing -高性能移动用户体验/。

Weevers, I., “Seven Guidelines for Designing High Performance Mobile User Experiences,” Smashing Magazine, July 18, 2011, available at http://uxdesign.smashingmagazine.com/2011/07/18/seven-guidelines-for-designing-high-performance-mobile-user-experiences/.

[欢迎01]

[Wel01]

vanWelie, M.,“交互设计模式”,2001。相关文章可以在 https://www.interaction-design.org/literature/article/10-great-sites-for-ui-design-patterns 上找到。

vanWelie, M., “Interaction Design Patterns,” 2001. A related article can be found at https://www.interaction-design.org/literature/article/10-great-sites-for-ui-design-patterns.

[惠08]

[Whi08]

White, J.,“启动您的引擎:移动应用程序开发”,2008 年 4 月 22 日,可从 http://www.devx.com/SpecialReports/Article/376​​93 获取。

White, J., “Start Your Engines: Mobile Application Development,” April 22, 2008, available at http://www.devx.com/SpecialReports/Article/37693.

[Wh12]

[Whi12]

Whittaker, J. 等人,Google 如何测试软件, Addison-Wesley,2012 年。

Whittaker, J., et al., How Google Tests Software, Addison-Wesley, 2012.

[Wh15]

[Whi15]

Whigham, PA、CA Owen 和 SG MacDonell,“软件工作量估计的基线模型”,ACM Transactions on Software Engineering and Methodology,卷。24、没有。2015 年 3 月,第 1-11 页。

Whigham, P. A., C. A. Owen, and S. G. MacDonell, “A Baseline Model for Software Effort Estimation,” ACM Transactions on Software Engineering and Methodology, vol. 24, no. 3, 2015, pp. 1–11.

[Wh97]

[Whi97]

Whitmire, S.,面向对象的设计测量, Wiley,1997。

Whitmire, S., Object-Oriented Design Measurement, Wiley, 1997.

[维伊02]

[Wie02]

Wiegers, K.,软件同行评审, Addison-Wesley,2002 年。

Wiegers, K., Peer Reviews in Software, Addison-Wesley, 2002.

[威尔05]

[Wil05]

Willoughby, M.,“Q&A:优质软件意味着更安全的软件”,Computerworld,

2005 年 3 月 21 日,网址为 https://www.computerworld.com/article/2563708/qa--quality-software-means-more- secure-software.html。

Willoughby, M., “Q&A: Quality Software Means More Secure Software,” Computerworld, March 21, 2005, available at https://www.computerworld.com/article/2563708/q-a--quality-

software-means-more-secure-software.html.

[威尔97]

[Wil97]

Williams, R.、J. Walker 和 A. Dorofee,“将风险管理付诸实践”,IEEE Software, 1997 年 5 月,第 75-81 页。

Williams, R., J. Walker, and A. Dorofee, “Putting Risk Management into Practice,” IEEE Software, May 1997, pp. 75–81.

[威尔71]

[Wir71]

Wirth, N.,“逐步细化的程序开发”,CACM,卷。14、没有。4,1971 年,第 221-227 页。

Wirth, N., “Program Development by Stepwise Refinement,” CACM, vol. 14, no. 4, 1971, pp. 221–227.

[威尔90]

[Wir90]

Wirfs-Brock, R.、B. Wilkerson 和 L. Weiner,《设计面向对象的软件》, Prentice Hall,1990 年。

Wirfs-Brock, R., B. Wilkerson, and L. Weiner, Designing Object-Oriented Software, Prentice Hall, 1990.

[WMT02]

[WMT02]

Web 映射测试台教程, 2002 年。相关演示文稿可在 http://proceedings.esri.com/library/userconf/devsum​​mit17/papers/dev_int_114.pdf 中找到。

Web Mapping Testbed Tutorial, 2002. A related presentation can be found at http://proceedings.esri.com/library/userconf/devsummit17/papers/dev_int_114.pdf.

[呜04]

[Woo04]

Woody, C.,引出和分析质量需求:管理对软件质量需求的影响(CMU/SEI-2005-TN-010、ADA441310)。宾夕法尼亚州匹兹堡:卡内基梅隆大学软件工程学院,2004 年,可访问 http://www.sei.cmu.edu/publications/documents/05.reports/05tn010.html。

Woody, C., Eliciting and Analyzing Quality Requirements: Management Influences on Software Quality Requirements (CMU/SEI-2005-TN-010, ADA441310). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2004, available at http://www.sei.cmu.edu/publications/documents/05.reports/05tn010.html.

[呜14]

[Woo14]

第658页Woody, C.、R. Ellison 和 W. Nichols,使用质量和可靠性措施预测软件保障, CMU/SEI-2014-TN-026,卡内基梅隆大学软件工程学院,2014 年,http://resources.sei .cmu.edu/library/asset-view.cfm?AssetID=428589。

Page 658Woody, C., R. Ellison, and W. Nichols, Predicting Software Assurance Using Quality and Reliability Measures, CMU/SEI-2014-TN-026, Software Engineering Institute, Carnegie Mellon University, 2014, http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=428589.

[呜89]

[Woo89]

Wood, J. 和 D. Silver,联合应用程序设计:如何在 40% 的时间内设计质量系统, John Wiley & Sons,1989 年。

Wood, J., and D. Silver, Joint Application Design: How to Design Quality Systems in 40% Less Time, John Wiley & Sons, 1989.

[Wri11]

[Wri11]

Wright, A.,“经验教训:建筑师也是促进者!” IEEE 软件,卷。28、没有。2,2011 年 1 月至 2 月,第 70-72 页。

Wright, A., “Lessons Learned: Architects Are Facilitators, Too!” IEEE Software, vol. 28, no. 2, January–February 2011, pp. 70–72.

[夏16]

[Xia16]

Xiao, L. 等人,“识别和量化架构债务”,第 38 届 ACM 国际软件工程会议论文集, 2016 年 5 月,第 488-498 页。

Xiao, L., et al., “Identifying and Quantifying Architectural Debt,” Proceedings of 38th ACM International Conference on Software Engineering, May 2016, pp. 488–498.

[谢18]

[Xie18]

Xie, T.,“智能软件工程:人工智能与软件工程之间的协同”,第 11 届软件工程创新会议 (ISEC '18) 论文集。ACM,纽约州纽约市,第 1 条,2018 年。

Xie, T., “Intelligent Software Engineering: Synergy between AI and Software Engineering,” Proceedings of the 11th Innovations in Software Engineering Conference (ISEC ’18). ACM, New York, NY, Article 1, 2018.

[亚德17]

[Yad17]

Yadav, H. 和 D. Yadav,“使用可靠性相关软件指标进行早期软件可靠性分析”,《国际系统保证工程与管理杂志》,卷。8,增刊,2017 年 12 月,第 2097-2108 页。

Yadav, H., and D. Yadav, “Early Software Reliability Analysis Using Reliability Relevant Software Metrics,” International Journal of System Assurance Engineering and Management, vol. 8, suppl., December 2017, pp. 2097–2108.

[尤11]

[Yau11]

Yau, S. 和 H. An,“软件工程遇见服务和云计算”,IEEE 计算机,卷。44,没有。10,2011 年 10 月,第 47-53 页。

Yau, S., and H. An, “Software Engineering Meets Services and Cloud Computing,” IEEE Computer, vol. 44, no. 10, October 2011, pp. 47–53.

[Yoo13]

[Yoo13]

Yoo, S. 和 M. Harman,“回归测试最小化、选择和优先级:一项调查”,《软件杂志:测试、验证和可靠性》,卷。22、没有。2,2013 年,第 67-120 页。

Yoo, S., and M. Harman, “Regression Testing Minimization, Selection and Prioritization: A Survey,” Journal of Software: Testing, Verification, and Reliability, vol. 22, no. 2, 2013, pp. 67–120.

[你01]

[You01]

Young, R.,《有效需求实践》, Addison-Wesley,2001 年。

Young, R., Effective Requirements Practices, Addison-Wesley, 2001.

[你18]

[You18]

Young, S.、T. Abdou 和 A. Bener,“复制研究:通过集成学习进行即时缺陷预测”,ACM/IEEE 第六届软件工程中实现人工智能协同效应国际研讨会论文集, ACM ,2018 年,第 42-47 页。

Young, S., T. Abdou, and A. Bener, “A Replication Study: Just-in-Time Defect Prediction with Ensemble Learning,” Proceedings of the ACM/IEEE Sixth International Workshop on Realizing Artificial Intelligence Synergies in Software Engineering, ACM, 2018, pp. 42–47.

[你75]

[You75]

Yourdon, E.,《程序结构和设计技术》, Prentice Hall,1975 年。

Yourdon, E., Techniques of Program Structure and Design, Prentice Hall, 1975.

[扎赫90]

[Zah90]

Zahniser, R.,“以小组方式构建软件”,《美国程序员》,卷。3、没有。1990 年 7 月至 8 月7 日至 8 日

Zahniser, R., “Building Software in Groups,” American Programmer, vol. 3, no. 7–8,

July–August 1990.

[扎赫94]

[Zah94]

Zahniser, R.,“顶尖团队绩效的时间盒”,软件开发, 1994 年 3 月,第 35-38 页。

Zahniser, R., “Timeboxing for Top Team Performance,” Software Development, March 1994, pp. 35–38.

[赞15]

[Zan15]

Zanoni, M.、Fontana, F. 和 Stella, F.“关于应用机器学习技术进行模式检测”,系统与软件杂志,卷。103,2015 年 5 月,第 102-117 页。

Zanoni, M., Fontana, F., and Stella, F. “On Applying Machine Learning Techniques for Pattern Detection,” Journal of Systems and Software, vol. 103, May 2015, pp. 102–117.

[赞18]

[Zan18]

Zancan, BAG 等人,“虚拟环境的辅助功能指南”,载于 M. Antona 和 C. Stephanidis(编辑),人机交互中的通用辅助功能。虚拟、增强和智能环境, UAHCI 2018。计算机科学讲义,卷。10908, 2018。

Zancan, B. A. G., et al., “Accessibility Guidelines for Virtual Environments,” in M. Antona and C. Stephanidis (eds.), Universal Access in Human-Computer Interaction. Virtual, Augmented, and Intelligent Environments, UAHCI 2018. Lecture Notes in Computer Science, vol. 10908, 2018.

[查13]

[Zha13]

张 D. 等人,“软件分析实践”,IEEE Software, 2013 年 9 月至 10 月,第 1 卷。30,没有。5,第 30-37 页。

Zhang, D., et al., “Software Analytics in Practice,” IEEE Software, September–October 2013, vol. 30, no. 5, pp. 30–37.

[Zim11]

[Zim11]

Zimmermann, O.,“作为可重用设计资产的架构决策”,IEEE Software,卷。28、没有。1,2011 年 1 月至 2 月,第 64-69 页。

Zimmermann, O., “Architectural Decisions as Reusable Design Assets,” IEEE Software, vol. 28, no. 1, January–February 2011, pp. 64–69.

[Zus90]

[Zus90]

Zuse, H.,软件复杂性:测量和方法, DeGruyter,1990。

Zuse, H., Software Complexity: Measures and Methods, DeGruyter, 1990.

[Zus97]

[Zus97]

Zuse, H.,软件测量框架, DeGruyter,1997。

Zuse, H., A Framework of Software Measurement, DeGruyter, 1997.

第659页

Page 659

指数_

Index

  • 抽象, 87, 163, 168

  • Abstraction, 87, 163, 168

  • 抽象维度,171–172

  • Abstraction dimension, 171–172

  • 虐待案件,363–364

  • Abuse cases, 363–364

  • 验收测试, 48, 68–69, 95, 430

  • Acceptance testing, 48, 68–69, 95, 430

  • 访问控制,450

  • Access control, 450

  • 无障碍, 233, 237, 259–261, 432–433

  • Accessibility, 233, 237, 259–261, 432–433

  • 行动,已定义,10

  • Action, defined, 10

  • 活动状态,150

  • Active state, 150

  • 活动,定义,9–10

  • Activity, defined, 9–10

  • 活动图,146–148、151–154、223、622–625

  • Activity diagrams, 146–148, 151–154, 223, 622–625

  • 活动网络,525–526

  • Activity networks, 525–526

  • 活动状态,627

  • Activity state, 627

  • 演员,114–115, 131

  • Actors, 114–115, 131

  • 适配器,230

  • Adapters, 230

  • 适应性维护, 70, 553

  • Adaptive maintenance, 70, 553

  • 美学设计, 237, 277

  • Aesthetic design, 237, 277

  • 审美指标,472

  • Aesthetic metrics, 472

  • 聚合,614–615

  • Aggregation, 614–615

  • 敏捷联盟,40–41

  • Agile Alliance, 40–41

  • 敏捷宣言,37、38、42

  • Agile manifesto, 37, 38, 42

  • 敏捷精神,41

  • Agile spirit, 41

  • 敏捷团队,40, 41, 78, 495

  • Agile teams, 40, 41, 78, 495

  • 敏捷

    • 应用,38-39

    • 变革管理,453–458

    • 38、40 的特征

    • 技术比较,52

    • 变革成本,39–40

    • 设计中, 60, 174, 185–186

    • 的发展, 38, 41

    • DevOps 方法,50–51

    • 第519章

    • 看板方法, 48–50, 56

    • 原则,40–41

    • 流程模型, 42–51, 56, 57

    • 需求工程, 58, 104

    • 评论中,336

    • Scrum 框架, 42–45, 56

    • 测试和,95

    • XP 框架,46–48

  • Agility

    • application of, 38–39

    • in change management, 453–458

    • characteristics of, 38, 40

    • comparison of techniques for, 52

    • cost of change and, 39–40

    • in design, 60, 174, 185–186

    • development of, 38, 41

    • DevOps approach to, 50–51

    • estimation and, 519

    • Kanban method for, 48–50, 56

    • principles of, 40–41

    • process models for, 42–51, 56, 57

    • in requirements engineering, 58, 104

    • in reviews, 336

    • Scrum framework for, 42–45, 56

    • testing and, 95

    • XP framework for, 46–48

  • 算法,62–63, 352, 606

  • Algorithms, 62–63, 352, 606

  • Alpha 测试,430

  • Alpha tests, 430

  • 环境情报,590

  • Ambient intelligence, 590

  • 分析

    • 攻击面,367

    • 边界值,389–390

    • 数据, 633

    • 错误/缺陷,342

    • 差距, 573

    • 危险,545

    • 影响, 443

    • 库存,563–564

    • 源代码,561

    • 静态, 368

    • 任务, 243, 247–248

    • 威胁,363

    • 用户界面,243–249

    • 工作环境,248–249

  • Analysis

    • attack surface, 367

    • boundary value, 389–390

    • data, 633

    • errors/defects, 342

    • gap, 573

    • hazards, 545

    • impact, 443

    • inventory, 563–564

    • source code, 561

    • static, 368

    • task, 243, 247–248

    • threats, 363

    • user interface, 243–249

    • work environment, 248–249

  • 分析类

    • 属性,140

    • 定义,104–105

    • 识别,137–140

    • 的表现,138

    • 选择特征,139–140

    • 状态图,150–151

  • Analysis classes

    • attributes for, 140

    • defined, 104–105

    • identifying, 137–140

    • manifestations of, 138

    • selection characteristics for, 139–140

    • state diagrams for, 150–151

  • 分析模型和建模。另请参见需求模型

    • 大楼,118–122

    • 的域,93

    • 119–121 的要素

    • 模式, 122

    • 原则,129–130

    • 目的,118

    • 经验法则,128–129

    • 术语,126

  • Analysis models and modeling. see also Requirements models

    • building, 118–122

    • domains of, 93

    • elements of, 119–121

    • patterns in, 122

    • principles of, 129–130

    • purpose of, 118

    • rules of thumb for, 128–129

    • terminology for, 126

  • 分析模式,122

  • Analysis patterns, 122

  • 分析,462–463、509–511、558–559

  • Analytics, 462–463, 509–511, 558–559

  • 锚点里程碑,29

  • Anchor point milestones, 29

  • 反窃听,382

  • Antibugging, 382

  • 反模式,302–304

  • Anti-patterns, 302–304

  • 反要求,383

  • Anti-requirements, 383

  • 应用领域,7

  • Application domains, 7

  • 应用对象,251

  • Application objects, 251

  • 应用软件,7

  • Application software, 7

  • 评估费用,317

  • Appraisal costs, 317

  • 原型,196–198

  • Archetypes, 196–198

  • 建筑背景图(ACD),196

  • Architectural context diagram (ACD), 196

  • 架构决策记录 (ADR),184

  • Architectural decision record (ADR), 184

  • 建筑决策,184–185、194–196

  • Architectural decisions, 184–185, 194–196

  • 建筑描述(公元),183–185

  • Architectural description (AD), 183–185

  • 架构描述语言(ADL),164

  • Architectural description language (ADL), 164

  • 建筑设计

    • 敏捷性, 60, 185–186

    • 201-204 中的替代方案

    • 原型,196–198

    • 经济, 193

    • 元素, 175

    • 出现于,194

    • 158、182的功能

    • 系统实例,200

    • 指标,466–467

    • 组织和细化,193

    • 模式, 187, 192–193, 203–204, 291, 299–300

    • 初步,59–60

    • 的属性, 164

    • 精炼成组件,198–200

    • 在上下文中表示系统,196–197

    • 间距,194

    • 风格,186–193

    • 对称性,194

    • 能见度,194

    • Web 应用程序,278–280

  • Architectural design

    • agility and, 60, 185–186

    • alternatives in, 201–204

    • archetypes in, 196–198

    • economy of, 193

    • elements of, 175

    • emergence in, 194

    • functions of, 158, 182

    • instantiations of system in, 200

    • metrics for, 466–467

    • organization and refinement of, 193

    • patterns, 187, 192–193, 203–204, 291, 299–300

    • preliminary, 59–60

    • properties of, 164

    • refining into components, 198–200

    • representing system in context, 196–197

    • spacing in, 194

    • styles of, 186–193

    • symmetry in, 194

    • visibility in, 194

    • of WebApps, 278–280

  • 架构不匹配,229–230

  • Architectural mismatch, 229–230

  • 建筑模式, 187, 192–193, 203–204, 291, 299–300

  • Architectural patterns, 187, 192–193, 203–204, 291, 299–300

  • 建筑评论,202–204

  • Architectural reviews, 202–204

  • 建筑学

    • 呼叫并返回,189

    • 一致性检查,204

    • 内容, 279

    • 以数据为中心,187–188

    • 数据流,188

    • 定义, 163–164, 173, 182

    • 侵蚀, 204

    • 功能性,226

    • 的重要性,183

    • 信息, 235, 279

    • 分层,189–192

    • 移动,273–274

    • MVC, 189, 191–192, 279–280

    • 面向对象,189

    • 重构,561–562

    • 责任驱动,186

    • 测试, 375, 376

  • Architecture

    • call-and-return, 189

    • conformance checking, 204

    • content, 279

    • data-centered, 187–188

    • data-flow, 188

    • defined, 163–164, 173, 182

    • erosion of, 204

    • functional, 226

    • importance of, 183

    • information, 235, 279

    • layered, 189–192

    • mobile, 273–274

    • MVC, 189, 191–192, 279–280

    • object-oriented, 189

    • refactoring, 561–562

    • responsibility-driven, 186

    • testing, 375, 376

  • 架构权衡分析方法(ATAM),201–202

  • Architecture trade-off analysis method (ATAM), 201–202

  • 人工智能(AI)

    • 应用程序涉及,7

    • 用于决策,229

    • 集成级测试和,403

    • 机器学习,294–295, 322

    • 建立可靠性模型,351–352

    • 软件工程和, 589, 606

    • 软件支持,以及,558

    • 测试,428–429

  • Artificial intelligence (AI)

    • applications involving, 7

    • for decision making, 229

    • integration-level testing and, 403

    • machine learning and, 294–295, 322

    • to model reliability, 351–352

    • software engineering and, 589, 606

    • software support and, 558

    • testing, 428–429

  • 评估。另见评估;风险评估

    • 建筑,202

    • 质量,314–315

    • 在软件改进过程中,572–573

    • 软件过程,24–25

  • Assessment. see also Evaluation; Risk assessment

    • architectural, 202

    • of quality, 314–315

    • in software improvement process, 572–573

    • of software process, 24–25

  • 评估工作,328

  • Assessment effort, 328

  • 协会,144, 154, 613–615

  • Associations, 144, 154, 613–615

  • 第660页原子模块,399

  • Page 660Atomic modules, 399

  • 攻击模式,363–364

  • Attack patterns, 363–364

  • 攻击面,366–367

  • Attack surface, 366–367

  • 属性

    • 定义,140–141

    • 指标数,462

    • 在软件质量保证方面,346

  • Attributes

    • defining, 140–141

    • of metrics, 462

    • in software quality assurance, 346

  • 审计、342、452、458、579

  • Audits, 342, 452, 458, 579

  • 审计追踪,445

  • Audit trails, 445

  • 创作,456

  • Authoring, 456

  • 自动化测试工具, 50, 413, 415, 422, 430

  • Automated testing tools, 50, 413, 415, 422, 430

  • 技术创新的自动化阶段,585

  • Automation phase of technology innovation, 585

  • 可用性,351

  • Availability, 351

  • 待办事项,43–45

  • Backlog, 43–45

  • 后向影响管理,451

  • Backward impact management, 451

  • 基线、441、442、450、481

  • Baselines, 441, 442, 450, 481

  • 基本路径测试,384–386

  • Basis path testing, 384–386

  • 贝叶斯推理,351–352

  • Bayesian inference, 351–352

  • 行为要素,120–121

  • Behavioral elements, 120–121

  • 行为建模

    • 活动图,151–154

    • 的特征,127

    • 识别事件与用例,149–150

    • 状态图,150–151

    • 创建步骤,149

  • Behavioral modeling

    • activity diagrams in, 151–154

    • characteristics of, 127

    • identifying events with use case in, 149–150

    • state diagrams in, 150–151

    • steps for creation of, 149

  • 行为模式,292–293

  • Behavioral patterns, 292–293

  • 行为测试,388–390、392–393

  • Behavioral testing, 388–390, 392–393

  • Beta 测试,430

  • Beta tests, 430

  • 集成测试的大爆炸方法,398

  • Big bang approach to integration testing, 398

  • 二元分类问题,634

  • Binary classification problems, 634

  • 黑盒指标,466

  • Black box metrics, 466

  • 黑盒测试,388–390, 397

  • Black-box testing, 388–390, 397

  • 蓝图隐喻,183

  • Blueprint metaphor, 183

  • 自下而上的整合,399–400

  • Bottom-up integration, 399–400

  • 边界测试,381–382

  • Boundary testing, 381–382

  • 边界值分析(BVA),389–390

  • Boundary value analysis (BVA), 389–390

  • 广度优先积分,398

  • Breadth-first integration, 398

  • 技术创新的突破阶段,585

  • Breakthrough phase of technology innovation, 585

  • 缓冲区溢出,367

  • Buffer overflow, 367

  • Bug,326。另请参见缺陷

  • Bugs, 326. see also Defects

  • 积木,591–592

  • Building blocks, 591–592

  • 构建安全成熟度模型 (BSIMM),370

  • Building Security in Maturity Model (BSIMM), 370

  • 业务活动监控,123

  • Business activity monitoring, 123

  • 业务目标,485

  • Business goals, 485

  • 商业风险,534

  • Business risks, 534

  • 调用和返回架构,189

  • Call-and-return architectures, 189

  • 能力成熟度模型集成 (CMMI), 370, 576–579

  • Capability Maturity Model Integration (CMMI), 370, 576–579

  • 捕捉/回放工具,403

  • Capture/playback tools, 403

  • 临时会议,331

  • Casual meetings, 331

  • 随意评论, 326, 331

  • Casual reviews, 326, 331

  • 分类变量,633

  • Categorical variables, 633

  • 认证测试,414

  • Certification testing, 414

  • 变化的来源,439

  • Change, sources of, 439

  • 变更控制、441、446、448–450、453–455

  • Change control, 441, 446, 448–450, 453–455

  • 变更控制机构 (CCA), 448, 450

  • Change control authority (CCA), 448, 450

  • 变更成本,39–40

  • Change costs, 39–40

  • 更改描述,455

  • Change descriptions, 455

  • 更换管理层

    • 敏捷,453–458

    • 流程,447–452

    • 在供应链管理中,445

    • 在 SQA 中,342

  • Change management

    • agile, 453–458

    • process for, 447–452

    • in SCM, 445

    • in SQA, 342

  • 变更报告,448

  • Change reports, 448

  • 变更请求,448

  • Change requests, 448

  • 零钱套装,446

  • Change sets, 446

  • 对遗留系统的更改,8

  • Changes to legacy systems, 8

  • 清单

    • 移动产品质量,285

    • 评论, 331

    • 风险项目,536

    • 验证要求,106

  • Checklists

    • mobile product quality, 285

    • for reviews, 331

    • risk item, 536

    • validation requirements, 106

  • 分块,227–228

  • Chunking, 227–228

  • CK 指标套件,469–471

  • CK metrics suite, 469–471

  • 基于类的设计指标,469–470

  • Class-based design metrics, 469–470

  • 基于类的元素,120

  • Class-based elements, 120

  • 基于类的建模

    • 的特征,127

    • 定义属性和操作,140–141

    • 确定分析类别,137–140

    • UML,141–144

  • Class-based modeling

    • characteristics of, 127

    • defining attributes and operations in, 140–141

    • identifying analysis classes in, 137–140

    • UML, 141–144

  • 类联轴器,218

  • Class coupling, 218

  • 类图,120、141、143、612–615

  • Class diagrams, 120, 141, 143, 612–615

  • 课程。另请参见分析类

    • 属性,140

    • 合作, 207

    • 定义, 120

    • 依赖者, 404

    • 设计,169–171

    • 等价,389

    • 层次结构, 469, 470

    • 独立,404

    • 运营,141

    • 服务器,404

  • Classes. see also Analysis classes

    • attributes, 140

    • collaborating, 207

    • defined, 120

    • dependent, 404

    • design, 169–171

    • equivalence, 389

    • hierarchies, 469, 470

    • independent, 404

    • operations, 141

    • server, 404

  • 分类问题,634

  • Classification problems, 634

  • 阶级-责任-合作者 (CRC) 模型,47, 144–146

  • Class-responsibility-collaborator (CRC) model, 47, 144–146

  • 课堂测试,390–391

  • Class testing, 390–391

  • 基于云的测试,428

  • Cloud-based testing, 428

  • 云计算,7, 273–274

  • Cloud computing, 7, 273–274

  • 聚类技术,637

  • Clustering technique, 637

  • 集群测试,404

  • Cluster testing, 404

  • CMMI 开发,24

  • CMMI-DEV, 24

  • 代码质量,345

  • Code quality, 345

  • 代码重构, 561, 564

  • Code refactoring, 561, 564

  • 编码活动,48, 95, 96, 367–368

  • Coding activity, 48, 95, 96, 367–368

  • 认知演练,246, 253

  • Cognitive walkthroughs, 246, 253

  • 凝聚力, 167, 170, 216–218, 468

  • Cohesion, 167, 170, 216–218, 468

  • 合作

    • 的好处, 89

    • 开发中,595–596

    • 在需求收集中,110–113

    • 利益相关者中,108

    • 第587章 587

  • Collaboration

    • benefits of, 89

    • in development, 595–596

    • in requirements gathering, 110–113

    • among stakeholders, 108

    • teams and, 587

  • 协作图、220、406、621

  • Collaboration diagrams, 220, 406, 621

  • CRC 建模领域的合作者,144

  • Collaborators, in CRC modeling, 144

  • 收集子系统,455–456

  • Collection subsystem, 455–456

  • 命令标签,260

  • Command labeling, 260

  • 共同封闭原则(CCP),215

  • Common closure principle (CCP), 215

  • 共同重用原则(CRP),215

  • Common reuse principle (CRP), 215

  • 沟通

    • 模式的有效性,89

    • 通过接口,257

    • 原则,88–90

    • 流程框架中,10

    • 在原型设计范式中,27

    • 为 23、24、500 设置的任务

    • 团队, 496, 604

  • Communication

    • effectiveness of modes of, 89

    • by interface, 257

    • principles of, 88–90

    • in process framework, 10

    • in prototyping paradigm, 27

    • task set for, 23, 24, 500

    • in teams, 496, 604

  • 沟通凝聚力,216

  • Communicational cohesion, 216

  • 通信图,189, 190, 621–622

  • Communication diagrams, 189, 190, 621–622

  • 区隔化, 521, 604

  • Compartmentalization, 521, 604

  • 兼容性测试,414

  • Compatibility testing, 414

  • 完整性,468

  • Completeness, 468

  • 复杂性,468, 588–589

  • Complexity, 468, 588–589

  • 基于组件的软件工程 (CBSE), 228–230, 509

  • Component-based software engineering (CBSE), 228–230, 509

  • 组件图,177

  • Component diagrams, 177

  • SCM 的组成元素,440

  • Component elements of SCM, 440

  • 组件级设计

    • 凝聚力,216–218

    • 耦合,218–219

    • 176–177 的要素

    • 示例,210–211

    • 158、206的功能

    • 指南,215–216

    • 对于移动应用程序,226–227

    • 模式,300–301

    • 原则, 173, 212–215

    • 专门化,225–230

    • 步骤,219–225

    • 对于传统组件,227–228

    • 对于网络应用程序,226, 282

  • Component-level design

    • cohesion in, 216–218

    • coupling in, 218–219

    • elements of, 176–177

    • example of, 210–211

    • functions of, 158, 206

    • guidelines for, 215–216

    • for MobileApps, 226–227

    • patterns in, 300–301

    • principles of, 173, 212–215

    • specialized, 225–230

    • steps for, 219–225

    • for traditional components, 227–228

    • for WebApps, 226, 282

  • 组件级测试

    • 黑匣子,388–390

    • 的元素, 372

    • 面向对象,390–393

    • 规划和记录保存,378–380

    • 战略方法,373–378

    • 测试用例设计,381–383

    • 白盒,383–387

  • Component-level testing

    • black-box, 388–390

    • elements of, 372

    • object-oriented, 390–393

    • planning and recordkeeping in, 378–380

    • strategic approach to, 373–378

    • test case design in, 381–383

    • white-box, 383–387

  • 成分

    • 基于班级,212–219

    • 定义,207

    • 详细阐述,207-209

    • 命名,215–216

    • 面向对象的观点,207–209

    • 与流程相关的视图,211–212

    • 重构,230–231

    • 重复利用, 214–215, 228, 229

    • 传统观点,209–211

  • Components

    • class-based, 212–219

    • defined, 207

    • elaboration of, 207–209

    • naming, 215–216

    • object-oriented view of, 207–209

    • process-related view of, 211–212

    • refactoring, 230–231

    • reuse of, 214–215, 228, 229

    • traditional view of, 209–211

  • 作文,615

  • Composition, 615

  • 计算智能,638

  • Computational intelligence, 638

  • 第661页计算机辅助软件工程,9

  • Page 661Computer-aided software engineering, 9

  • 概念开发项目,524–526

  • Concept development projects, 524–526

  • 关注点,165。另请参见关注点分离

  • Concerns, 165. see also Separation of concerns

  • 状态测试,386

  • Condition testing, 386

  • 条件-转移-结果 (CTC) 格式,542

  • Condition-transition-consequence (CTC) format, 542

  • 配置审核,452

  • Configuration audits, 452

  • 配置管理,11, 437, 445。另请参见软件配置管理

  • Configuration management, 11, 437, 445. see also Software configuration management

  • 配置对象、441–443、445–446、450、452、457–458

  • Configuration objects, 441–443, 445–446, 450, 452, 457–458

  • 配置评论,408

  • Configuration reviews, 408

  • 配置状态报告,452

  • Configuration status reporting, 452

  • 联结主义,636–637

  • Connectionism, 636–637

  • 连接性和连接性测试,414、587

  • Connectivity and connectivity testing, 414, 587

  • 一致性, 87, 240–241, 257

  • Consistency, 87, 240–241, 257

  • 建造

    • 接口数量,243

    • 作为统一流程的阶段,33

    • 95-98 的原则

    • 流程框架中,10

  • Construction

    • of interface, 243

    • as phase of Unified Process, 33

    • principles of, 95–98

    • in process framework, 10

  • SCM 的构建要素,440

  • Construction elements of SCM, 440

  • 建设性成本模型(COCOMO),511

  • Constructive cost model (COCOMO), 511

  • 内容架构,279

  • Content architecture, 279

  • 内容耦合,218

  • Content coupling, 218

  • 内容设计,277–278

  • Content design, 277–278

  • 内容管理, 455, 456

  • Content management, 455, 456

  • 内容指标,473

  • Content metrics, 473

  • 内容对象,277–278

  • Content objects, 277–278

  • 内容存储库,444

  • Content repository, 444

  • 内容测试,420–421

  • Content testing, 420–421

  • 上下文感知应用程序,274–275

  • Context-aware apps, 274–275

  • 上下文无关问题,108

  • Context-free questions, 108

  • 上下文变量,427

  • Context variables, 427

  • 应急计划,86, 92, 544

  • Contingency planning, 86, 92, 544

  • 持续集成 (CI)、400–402、446–447

  • Continuous integration (CI), 400–402, 446–447

  • 持续流程改进,341

  • Continuous process improvement, 341

  • 连续变量,633

  • Continuous variables, 633

  • 合同软件,342

  • Contracted software, 342

  • 控制联轴器,218

  • Control coupling, 218

  • 控制结构测试,386–387

  • Control structure testing, 386–387

  • 收敛,157

  • Convergence, 157

  • 团队协调,496

  • Coordination of teams, 496

  • 纠正性维护,69–70, 553

  • Corrective maintenance, 69–70, 553

  • 变革成本,39–40

  • Cost of change, 39–40

  • 质量成本,317–318

  • Cost of quality, 317–318

  • 联轴器, 167, 170, 174, 218–219, 468

  • Coupling, 167, 170, 174, 218–219, 468

  • 对象类之间的耦合 (CBO),469–470

  • Coupling between object classes (CBO), 469–470

  • 创作模式,292

  • Creational patterns, 292

  • 关键路径, 520, 526

  • Critical path, 520, 526

  • 项目管理的关键实践,502

  • Critical practices for project management, 502

  • 众包,423

  • Crowdsourcing, 423

  • 客户旅程地图,244–245

  • Customer journey maps, 244–245

  • 客户,定义,88

  • Customers, defined, 88

  • 客户满意度,40–41

  • Customer satisfaction, 40–41

  • 客户测试。参见验收测试

  • Customer testing. see Acceptance testing

  • 圈复杂度,385–386

  • Cyclomatic complexity, 385–386

  • 数据抽象,163

  • Data abstraction, 163

  • 数据分析,633

  • Data analysis, 633

  • 数据分析,509–511

  • Data analytics, 509–511

  • 以数据为中心的架构,187–188

  • Data-centered architectures, 187–188

  • 数据清理,633

  • Data cleaning, 633

  • 数据收集,633

  • Data collection, 633

  • 数据复杂性,467

  • Data complexity, 467

  • 数据设计, 173, 174

  • Data design, 173, 174

  • 数据流架构,188

  • Data-flow architectures, 188

  • 数据流程图 (DFD), 365, 366

  • Data flow diagrams (DFDs), 365, 366

  • 数据流测试,381、386

  • Data flow testing, 381, 386

  • 数据模型,127

  • Data models, 127

  • 数据修改, 630, 633

  • Data munging, 630, 633

  • 数据名称合理化,561

  • Data name rationalization, 561

  • 数据模式,291

  • Data patterns, 291

  • 数据处理,605

  • Data processing, 605

  • 数据记录标准化,561

  • Data record standardization, 561

  • 数据重新设计,561

  • Data redesign, 561

  • 数据重构, 561, 564–565

  • Data refactoring, 561, 564–565

  • 数据科学

    • 数据分析,633

    • 461、629 的特征

    • 清理数据,633

    • 第637章 聚类技术

    • 收集数据,633

    • 计算智能,以及,638

    • 决策树,634–635

    • 第637章 降维

    • 语言选择,629–631

    • 第 631 章

    • 机器学习和,631–637

    • 最近邻技术,635–637

    • 神经网络,636–637

    • 第638章

    • 训练集制作,633

    • 数据转换,633

  • Data science

    • analysis of data in, 633

    • characteristics of, 461, 629

    • cleaning data in, 633

    • clustering technique in, 637

    • collecting data in, 633

    • computational intelligence and, 638

    • decision trees in, 634–635

    • dimensional reduction in, 637

    • language selection for, 629–631

    • libraries and tools for, 631

    • machine learning and, 631–637

    • nearest neighbor technique in, 635–637

    • neural networks in, 636–637

    • search-based software engineering and, 638

    • training set fabrication in, 633

    • transformation of data in, 633

  • 数据转换,633

  • Data transformation, 633

  • 调试,123

  • Debugging, 123

  • 决策隐喻,184

  • Decision metaphor, 184

  • 决策树,634–635

  • Decision trees, 634–635

  • 决策视图,195

  • Decision view, 195

  • 分解,497–500, 511–519

  • Decomposition, 497–500, 511–519

  • 缺陷去除效率 (DRE), 482–484, 486

  • Defect removal efficiency (DRE), 482–484, 486

  • 缺陷

    • 放大, 327

    • 收集和分析,342

    • 成本影响,326–327

    • 定义, 478

    • 预测, 322

    • 第327章

    • 追踪,446

  • Defects

    • amplification of, 327

    • collection and analysis of, 342

    • cost impact of, 326–327

    • defined, 478

    • prediction of, 322

    • propagation of, 327

    • tracking, 446

  • 缺陷清单,408

  • Deficiency lists, 408

  • 严格程度,524

  • Degree of rigor, 524

  • 结构不确定性程度,506

  • Degree of structural uncertainty, 506

  • 依赖关系, 154, 216, 442–443, 445, 614

  • Dependencies, 154, 216, 442–443, 445, 614

  • 依赖倒置原则(DIP),214

  • Dependency inversion principle (DIP), 214

  • 附属类别,404

  • Dependent classes, 404

  • 部署

    • 在 DevOps 方法中,50

    • 在移动开发生命周期中,269

    • 98-100 的原则

    • 流程框架,11

    • 原型设计,63

  • Deployment

    • in DevOps approach, 50

    • in mobile development life cycle, 269

    • principles of, 98–100

    • in process framework, 11

    • prototyping and, 63

  • 部署图, 177, 178, 225, 615–616

  • Deployment diagrams, 177, 178, 225, 615–616

  • 部署级设计,177–178

  • Deployment-level design, 177–178

  • 深度优先积分,398

  • Depth-first integration, 398

  • 继承树的深度 (DIT), 469, 475

  • Depth of the inheritance tree (DIT), 469, 475

  • 部署图的描述符形式,178

  • Descriptor form of deployment diagrams, 178

  • 设计

    • 敏捷性,60、174、185–186

    • 建筑(参见建筑设计)

    • 组件级(参见组件级设计)

    • 的概念(参见设计概念)

    • 内容,277–278

    • 在软件工程背景下,157–159

    • 收敛于,157

    • 数据, 173, 174

    • 定义, 181

    • 部署级,177–178

    • 多元化,157

    • 占主导地位, 184

    • 评价, 160, 161, 253–256

    • 演变,161–162

    • 的重要性, 3, 159

    • 界面(参见界面设计)

    • 等级, 456

    • 指标, 466–473, 475

    • 移动(请参阅移动应用程序)

    • 在移动开发生命周期中,268

    • 模型(参见设计模型)

    • 导航,280–282

    • 面向对象的方法, 161, 173

    • 基于模式(参见基于模式的设计)

    • 练习, 156

    • 原则,156

    • 流程,159–162

    • 质量, 159–161, 282–285, 311, 345

    • 重构, 48, 168, 225

    • 细化,167–168

    • 任务设定,162

    • 测试用例,381–383、405–407

    • 用户交互,236

    • 视觉, 237, 277

    • 在 XP 框架中,47–48

  • Design

    • agility in, 60, 174, 185–186

    • architectural (see Architectural design)

    • component-level (see Component-level design)

    • concepts of (see Design concepts)

    • content, 277–278

    • in context of software engineering, 157–159

    • convergence in, 157

    • of data, 173, 174

    • defined, 181

    • deployment-level, 177–178

    • diversification in, 157

    • dominant, 184

    • evaluation of, 160, 161, 253–256

    • evolution of, 161–162

    • importance of, 3, 159

    • interface (see Interface design)

    • level, 456

    • metrics for, 466–473, 475

    • mobile (see MobileApps)

    • in mobile development life cycle, 268

    • models (see Design models)

    • navigation, 280–282

    • object-oriented approach to, 161, 173

    • pattern-based (see Pattern-based design)

    • practice, 156

    • principles, 156

    • process for, 159–162

    • quality of, 159–161, 282–285, 311, 345

    • refactoring, 48, 168, 225

    • refinement of, 167–168

    • task set for, 162

    • test case, 381–383, 405–407

    • user interaction, 236

    • visual, 237, 277

    • in XP framework, 47–48

  • 设计课程,169–171

  • Design classes, 169–171

  • 第662页设计理念

    • 抽象, 163, 168

    • 建筑,163–164

    • 课程,169–171

    • 功能独立,167

    • 的重要性,156

    • 信息隐藏,166

    • 模块化,165–166

    • 模式,164–165

    • 重构, 48, 168, 225

    • 关注点分离,165

    • 逐步细化,167–168

  • Page 662Design concepts

    • abstraction, 163, 168

    • architecture, 163–164

    • classes, 169–171

    • functional independence, 167

    • importance of, 156

    • information hiding, 166

    • modularity, 165–166

    • patterns, 164–165

    • refactoring, 48, 168, 225

    • separation of concerns, 165

    • stepwise refinement, 167–168

  • 设计模型

    • 建筑,175

    • 所代表的特征,93

    • 组件级,176–177

    • 对于数据,174

    • 部署级,177–178

    • 尺寸,171–172

    • 对于接口,175–176

    • 原则,173–174

    • 需求模型的翻译,158

  • Design models

    • architectural, 175

    • characteristics represented by, 93

    • component-level, 176–177

    • for data, 174

    • deployment-level, 177–178

    • dimensions of, 171–172

    • for interfaces, 175–176

    • principles for, 173–174

    • translation from requirements models, 158

  • 设计模式。请参阅基于模式的设计

  • Design patterns. see Pattern-based design

  • 设计恢复,564

  • Design recovery, 564

  • 设计结构质量指数(DSQI),468

  • Design structure quality index (DSQI), 468

  • 案头检查,331–332

  • Desk checks, 331–332

  • 确定软件,7

  • Determinate software, 7

  • 开发者笔记,195

  • Developer notes, 195

  • 开发团队, 43–45, 67

  • Development teams, 43–45, 67

  • 设备兼容性测试,414

  • Device compatibility testing, 414

  • DevOps 方法,50–51

  • DevOps approach, 50–51

  • 图表

    • 活动, 146–148, 151–154, 223, 622–625

    • 建筑环境,196

    • 班级, 120, 141, 143, 612–615

    • 协作, 220, 406, 621

    • 通讯, 189, 190, 621–622

    • 组件,177

    • 数据流, 365, 366

    • 部署, 177, 178, 225, 615–616

    • 序列,148–149, 618–621

    • 州、120–121、150–151、392、625–628

    • 泳道, 151, 153–154

    • 用例, 118, 119, 136, 137, 616–618

  • Diagrams

    • activity, 146–148, 151–154, 223, 622–625

    • architectural context, 196

    • class, 120, 141, 143, 612–615

    • collaboration, 220, 406, 621

    • communication, 189, 190, 621–622

    • component, 177

    • data flow, 365, 366

    • deployment, 177, 178, 225, 615–616

    • sequence, 148–149, 618–621

    • state, 120–121, 150–151, 392, 625–628

    • swimlane, 151, 153–154

    • use case, 118, 119, 136, 137, 616–618

  • 降维,637

  • Dimensional reduction, 637

  • 直接措施,479–480

  • Direct measures, 479–480

  • 分布式调试,123

  • Distributed debugging, 123

  • 多元化,157

  • Diversification, 157

  • 做活动,627

  • Do-activity, 627

  • 文档测试,434

  • Documentation testing, 434

  • 文件重组,564

  • Document restructuring, 564

  • 特定领域建模语言 (DSML),597

  • Domain-specific modeling languages (DSMLs), 597

  • 主导设计,184

  • Dominant design, 184

  • 司机, 379, 399

  • Drivers, 379, 399

  • 动态模型,164

  • Dynamic models, 164

  • 动态测试,429

  • Dynamic testing, 429

  • 教育和培训, 342, 573

  • Education and training, 342, 573

  • 效率,257

  • Efficiency, 257

  • 努力验证,521

  • Effort validation, 521

  • 无私编程,64–65

  • Egoless programming, 64–65

  • 阐述

    • 在沟通活动中,23

    • 组件数量,207–209

    • 作为统一流程的阶段,33

    • 问题,497–498

    • 细化过程,167–168, 248

    • 需求工程,104–105

  • Elaboration

    • in communication activity, 23

    • of components, 207–209

    • as phase of Unified Process, 33

    • problem, 497–498

    • refinement as process of, 167–168, 248

    • in requirements engineering, 104–105

  • 引出。另请参阅需求收集

    • 敏捷,104

    • 在交流活动中,23, 24

    • 需求工程,104, 109

    • 安全需求,362

    • 114、第 114 章

  • Elicitation. see also Requirements gathering

    • agile, 104

    • in communication activity, 23, 24

    • in requirements engineering, 104, 109

    • of security needs, 362

    • work products produced during, 114

  • 嵌入式软件,7

  • Embedded software, 7

  • 经验估计模型,510–511

  • Empirical estimation models, 510–511

  • 技术创新的经验主义阶段,585

  • Empiricism phase of technology innovation, 585

  • 封装,475

  • Encapsulation, 475

  • 最终用户,已定义,88

  • End users, defined, 88

  • 工程。另请参阅软件工程

    • 算法,62–63

    • 特征, 634

    • 前锋, 565

    • 再造, 554, 562–565

    • 反向, 553–557, 564

    • 安全, 357, 360–363

  • Engineering. see also Software engineering

    • algorithms, 62–63

    • feature, 634

    • forward, 565

    • reengineering, 554, 562–565

    • reverse, 553–557, 564

    • security, 357, 360–363

  • 工程变更单 (ECO)、448、450、452

  • Engineering change order (ECO), 448, 450, 452

  • 工程软件,7

  • Engineering software, 7

  • 整体学习环境,635

  • Ensemble learning environment, 635

  • 环境资源,509

  • Environmental resources, 509

  • 同等课程,389

  • Equivalence classes, 389

  • 等价划分,389

  • Equivalence partitioning, 389

  • 错误

    • 收集和分析,342

    • 成本,317–318

    • 定义, 326, 478

    • 密度, 328, 329

    • 处理系统,260

  • Errors

    • collection and analysis of, 342

    • cost of, 317–318

    • defined, 326, 478

    • density of, 328, 329

    • handling systems, 260

  • 估计。另请参阅项目规划

    • 敏捷开发,519

    • 项目的复杂性,505–506

    • 数据分析和,509–511

    • 分解技术,511–519

    • 经验模型,510–511

    • 基于 FP,514–515

    • 基于 LOC,512–513

    • 92 的目标

    • 基于问题,512

    • 基于流程,515–516

    • 质量和,321

    • 协调估计,518-519

    • 资源, 60–61, 505

    • 风险,538–541

    • 506 项目规模

    • 软件大小调整,511

    • 用例,517–518

  • Estimation. see also Project planning

    • for agile development, 519

    • complexity of projects and, 505–506

    • data analytics and, 509–511

    • decomposition techniques, 511–519

    • empirical models for, 510–511

    • FP-based, 514–515

    • LOC-based, 512–513

    • objectives of, 92

    • problem-based, 512

    • process-based, 515–516

    • quality and, 321

    • reconciling estimates, 518–519

    • of resources, 60–61, 505

    • of risk, 538–541

    • size of projects and, 506

    • software sizing, 511

    • use case, 517–518

  • 伦理学,607–609

  • Ethics, 607–609

  • 民族志观察,272

  • Ethnographic observation, 272

  • 评估。另见评估

    • 设计, 160, 161, 253–256

    • 界面设计,253–256

    • 尸检,336

    • 原型开发中,64–65、68–69、253–254

    • 在软件过程改进方面,575

  • Evaluation. see also Assessment

    • of design, 160, 161, 253–256

    • of interface design, 253–256

    • post-mortem, 336

    • in prototype development, 64–65, 68–69, 253–254

    • in software process improvement, 575

  • 进化流程,22, 23

  • Evolutionary process flow, 22, 23

  • 进化过程模型,29–31, 56–57, 67

  • Evolutionary process models, 29–31, 56–57, 67

  • 例外情况,134–135

  • Exceptions, 134–135

  • 详尽的测试,380

  • Exhaustive testing, 380

  • 风险暴露,540–541

  • Exposure to risk, 540–541

  • 可扩展标记语言(XML),273

  • Extensible Markup Language (XML), 273

  • 外部联轴器,218

  • External coupling, 218

  • 外部故障成本,317

  • External failure costs, 317

  • 额外功能特性,164

  • Extra-functional properties, 164

  • 极限编程 (XP), 46–48, 67

  • Extreme Programming (XP), 46–48, 67

  • 失败成本,317

  • Failure costs, 317

  • 失效曲线,5–6

  • Failure curves, 5–6

  • 及时故障 (FIT),351

  • Failures in time (FIT), 351

  • 相关系统系列,164

  • Families of related systems, 164

  • 扇入(FIN),475

  • Fan-in (FIN), 475

  • 基于故障的测试,405–406

  • Fault-based testing, 405–406

  • 故障,326。另见缺陷

  • Faults, 326. see also Defects

  • 特征工程,634

  • Feature engineering, 634

  • 特征向量,633

  • Feature vectors, 633

  • 过滤器,188

  • Filters, 188

  • 财务杠杆,571

  • Financial leverage, 571

  • 消防模式,533

  • Fire-fighting mode, 533

  • 系统工程第一定律,438–439

  • First law of system engineering, 438–439

  • 灵活性,258

  • Flexibility, 258

  • 流程图,384

  • Flow graphs, 384

  • 面向流量的模型,127

  • Flow-oriented models, 127

  • 正式变更控制,450

  • Formal change control, 450

  • 正式技术审查 (FTR), 327, 332–335

  • Formal technical reviews (FTRs), 327, 332–335

  • 正式用例,127, 135

  • Formal use cases, 127, 135

  • 正向工程,565

  • Forward engineering, 565

  • 前瞻性影响管理,451

  • Forward impact management, 451

  • 基于 FP 的估计,514–515

  • FP-based estimation, 514–515

  • 构架

    • 型号, 164

    • 基于模式的设计,293

    • 风险管理,364–365

    • Scrum, 42–45, 56, 66–67

    • 软件流程, 10–11, 21, 23

    • 软件过程改进,569–570

  • Frameworks

    • models, 164

    • pattern-based design, 293

    • risk management, 364–365

    • Scrum, 42–45, 56, 66–67

    • software process, 10–11, 21, 23

    • software process improvement, 569–570

  • 功能架构,226

  • Functional architecture, 226

  • 功能内聚力,216

  • Functional cohesion, 216

  • 功能独立性,167, 173

  • Functional independence, 167, 173

  • 功能建模,146–149, 164

  • Functional modeling, 146–149, 164

  • 功能测试, 97, 388–390, 397

  • Functional testing, 97, 388–390, 397

  • 面向功能的指标,481

  • Function-oriented metrics, 481

  • 功能点 (FP)、481、514–515

  • Function point (FP), 481, 514–515

  • 模糊逻辑,539

  • Fuzzy logic, 539

  • 第663页游戏化,544–545

  • Page 663Gamification, 544–545

  • 甘特图,527

  • Gantt charts, 527

  • 差距分析,573

  • Gap analysis, 573

  • 概括,613

  • Generalizations, 613

  • 生成模式,291

  • Generative patterns, 291

  • 通用过程模型,21–23

  • Generic process models, 21–23

  • 一般风险,535

  • Generic risks, 535

  • 遗传算法, 352, 606

  • Genetic algorithms, 352, 606

  • 手势测试,415–416

  • Gesture testing, 415–416

  • 玻璃盒测试,383–387, 397

  • Glass-box testing, 383–387, 397

  • 全球化,587–588

  • Globalization, 587–588

  • 全球软件开发 (GSD) 团队,80–81

  • Global software development (GSD) teams, 80–81

  • 进行、不进行的决定,65–67

  • Go, no-go decisions, 65–67

  • 背景下的目标,135

  • Goal in context, 135

  • 目标

    • 商业, 485

    • 定义,104

    • 界面设计,243

    • 需求收集,24

    • 安全, 362

    • 软件质量保证,345–346

  • Goals

    • business, 485

    • defined, 104

    • of interface design, 243

    • of requirements gathering, 24

    • security, 362

    • of software quality assurance, 345–346

  • “足够好”的软件,316

  • “Good enough” software, 316

  • 语法分析, 137, 138, 141

  • Grammatical parse, 137, 138, 141

  • 粒度,92

  • Granularity, 92

  • 平面设计, 237, 277

  • Graphic design, 237, 277

  • 平面设计指标,472

  • Graphic design metrics, 472

  • 图形图标,276

  • Graphic icons, 276

  • 图形图像,276

  • Graphic images, 276

  • 握手,122

  • Handshaking, 122

  • 硬件,故障曲线,5–6

  • Hardware, failure curve for, 5–6

  • 危险,352–353, 545

  • Hazards, 352–353, 545

  • 帮助设施,260, 434

  • Help facilities, 260, 434

  • 启发式评估,253

  • Heuristic evaluations, 253

  • 启发式, 7, 157, 162, 554

  • Heuristics, 7, 157, 162, 554

  • 高粒度计划,92

  • High-granularity plans, 92

  • 高阶测试,377

  • High-order testing, 377

  • 历史数据,481

  • Historical data, 481

  • 钩子,293

  • Hooks, 293

  • SCM 的人为因素,440

  • Human elements of SCM, 440

  • 以人为本的道路,599

  • Human-focused path, 599

  • 人机界面对象,258

  • Human interface objects, 258

  • 人力资源,508

  • Human resources, 508

  • 新兴技术的炒作周期,586–587

  • Hype cycle for emerging technologies, 586–587

  • 鉴别

    • 分析课程数,137–140

    • 具有用例的事件,149–150

    • 风险,535–537

    • 利益相关者数量,107

  • Identification

    • of analysis classes, 137–140

    • of events with use cases, 149–150

    • of risk, 535–537

    • of stakeholders, 107

  • 成语, 292

  • Idioms, 292

  • 影响分析,443

  • Impact analysis, 443

  • 影响力管理, 443, 451

  • Impact management, 443, 451

  • 风险的影响,540–541

  • Impact of risk, 540–541

  • 实施模型,242

  • Implementation model, 242

  • 盗梦空间

    • 在沟通活动中,23

    • 在移动开发生命周期中,268

    • 作为统一流程的阶段,32

    • 需求工程,104

  • Inception

    • in communication activity, 23

    • in mobile development life cycle, 268

    • as phase of Unified Process, 32

    • in requirements engineering, 104

  • 增量发展战略,40

  • Incremental development strategies, 40

  • 增量过程模型,55–56

  • Incremental process models, 55–56

  • 增量。请参阅软件增量

  • Increments. see Software increments

  • 独立班,404

  • Independent classes, 404

  • 独立路径,384–385

  • Independent paths, 384–385

  • 独立测试组 (ITG),375

  • Independent test groups (ITGs), 375

  • 不确定软件,7

  • Indeterminate software, 7

  • 指标,已定义,462

  • Indicators, defined, 462

  • 非正式变更控制,450

  • Informal change control, 450

  • 信息架构, 235, 279

  • Information architecture, 235, 279

  • 信息传递,4

  • Information delivery, 4

  • 信息领域,129

  • Information domain, 129

  • 信息隐藏,166

  • Information hiding, 166

  • 信息目标,497

  • Information objectives, 497

  • 信息技术,605

  • Information technology, 605

  • 继承, 216, 475

  • Inheritance, 216, 475

  • 检查, 326, 332

  • Inspections, 326, 332

  • 安装,574–575

  • Installation, 574–575

  • 部署图实例形式,178

  • Instance form of deployment diagrams, 178

  • 可积性,187

  • Integrability, 187

  • 一体化

    • 自下而上,399–400

    • 广度优先,398

    • 连续、400–402、446–447

    • 深度优先,398

    • 在 DevOps 方法中,50

    • 自上而下,398–399

  • Integration

    • bottom-up, 399–400

    • breadth-first, 398

    • continuous, 400–402, 446–447

    • depth-first, 398

    • in DevOps approach, 50

    • top-down, 398–399

  • 集成级测试

    • 建筑学, 375, 376

    • 人工智能和,403

    • 黑匣子,397

    • 自下而上,399–400

    • 挑战, 395

    • 在建筑活动中,95

    • 基础知识,396–397

    • 第 398 章

    • 面向对象,404–407

    • 图案, 409

    • 回归,403–404

    • 自上而下,398–399

    • 验证,407–408

    • 白盒,397

    • 工作产品,402

  • Integration-level testing

    • of architecture, 375, 376

    • artificial intelligence and, 403

    • black-box, 397

    • bottom-up, 399–400

    • challenges of, 395

    • in construction activity, 95

    • fundamentals of, 396–397

    • objectives of, 398

    • object-oriented, 404–407

    • patterns, 409

    • regression, 403–404

    • top-down, 398–399

    • validation, 407–408

    • white-box, 397

    • work products, 402

  • 诚信,483

  • Integrity, 483

  • 智能软件工程,606

  • Intelligent software engineering, 606

  • 交互设计,236

  • Interaction design, 236

  • 交互帧,620

  • Interaction frames, 620

  • 互动机制,234

  • Interaction mechanisms, 234

  • 相互依存,521

  • Interdependency, 521

  • 界面分析,243

  • Interface analysis, 243

  • 接口构建,243

  • Interface construction, 243

  • 界面设计。另请参阅用户体验设计

    • 元素,175–176

    • 评估,253–256

    • 的功能,158

    • 目标, 243

    • 黄金法则, 234, 238–241

    • 指南, 216, 259

    • 指标,471–473

    • 对于移动应用程序,261、270–271

    • 型号, 241–242, 270–271

    • 模式, 252–253, 291, 304–305

    • 用于让用户控制,238–239

    • 的原则,173

    • 流程,242–243

    • 用于减少用户的内存负载,239–240

    • 步骤,251–252

    • 对于 Web 应用程序,275–276

  • Interface design. see also User experience design

    • elements of, 175–176

    • evaluation of, 253–256

    • functions of, 158

    • goals of, 243

    • golden rules of, 234, 238–241

    • guidelines for, 216, 259

    • metrics for, 471–473

    • for MobileApps, 261, 270–271

    • models for, 241–242, 270–271

    • patterns in, 252–253, 291, 304–305

    • for placing user in control, 238–239

    • principles of, 173

    • process for, 242–243

    • for reducing user’s memory load, 239–240

    • steps for, 251–252

    • for WebApps, 275–276

  • 接口隔离原则(ISP),214

  • Interface segregation principle (ISP), 214

  • 接口测试, 388, 421

  • Interface testing, 388, 421

  • 接口验证,243

  • Interface validation, 243

  • 内部故障成本,317

  • Internal failure costs, 317

  • 国际化,260–261, 423

  • Internationalization, 260–261, 423

  • 库存分析,563–564

  • Inventory analysis, 563–564

  • ISO 9001:2015, 353–354

  • ISO 9001:2015, 353–354

  • 问题列表,112

  • Issues lists, 112

  • 问题跟踪,69, 446

  • Issues tracking, 69, 446

  • 迭代规划, 91, 92

  • Iterative planning, 91, 92

  • 迭代流程,22, 23

  • Iterative process flow, 22, 23

  • 果冻队, 76–77, 494

  • Jelled teams, 76–77, 494

  • 论证活动,573–574

  • Justification activity, 573–574

  • 看板方法,48–50, 56, 67

  • Kanban method, 48–50, 56, 67

  • 关键绩效指标 (KPI),462

  • Key performance indicators (KPIs), 462

  • 知识发现,605–606

  • Knowledge discovery, 605–606

  • 已知风险,535

  • Known risks, 535

  • 方法缺乏凝聚力 (LCOM), 470, 475

  • Lack of cohesion in methods (LCOM), 470, 475

  • 语言隐喻,183

  • Language metaphor, 183

  • 语言

    • 架构描述,164

    • 对于数据科学,629–631

    • 特定领域建模,597

    • 图案, 297

    • UML(参见统一建模语言)

  • Languages

    • architectural description, 164

    • for data science, 629–631

    • domain-specific modeling, 597

    • pattern, 297

    • UML (see Unified modeling language)

  • 延迟减少,258

  • Latency reduction, 258

  • 德米特定律,170

  • Law of Demeter, 170

  • 层内聚力, 216, 217

  • Layer cohesion, 216, 217

  • 分层架构,189–192

  • Layered architectures, 189–192

  • 分层行为模型,75–76

  • Layered behavioral model, 75–76

  • 布局, 277, 431

  • Layout, 277, 431

  • 领导力,493–494

  • Leadership, 493–494

  • 易学性,258

  • Learnability, 258

  • 旧版软件,8

  • Legacy software, 8

  • 关卡设计,456

  • Level design, 456

  • 责任,320

  • Liability, 320

  • 图书馆,631

  • Libraries, 631

  • 生命周期安全模型,357–359

  • Life-cycle security models, 357–359

  • 线性工艺流程, 22, 23

  • Linear process flow, 22, 23

  • 线性顺序模型。参见瀑布模型

  • Linear sequential model. see Waterfall model

  • 里氏替换原理(LSP),214

  • Liskov substitution principle (LSP), 214

  • 听力, 46, 89

  • Listening, 46, 89

  • 文学隐喻,184

  • Literature metaphor, 184

  • 负载测试,425–426

  • Load testing, 425–426

  • 本地化, 260, 423

  • Localization, 260, 423

  • 基于 LOC 的估计,512–513

  • LOC-based estimation, 512–513

  • 基于 LOC 的指标,481

  • LOC-based metrics, 481

  • 第664页循环测试,387

  • Page 664Loop testing, 387

  • 低粒度计划,92

  • Low-granularity plans, 92

  • 机器学习,294–295、322、558、606、631–637

  • Machine learning, 294–295, 322, 558, 606, 631–637

  • 主程序/子程序架构,189

  • Main program/subprogram architectures, 189

  • 可维护性, 483, 553

  • Maintainability, 483, 553

  • 维护

    • 自适应, 70, 553

    • 第552章 的挑战

    • 纠正, 69–70, 553

    • 定义, 69

    • 的重要性, 3, 71

    • 指标,476

    • 完成时, 70, 553

    • 实践原则,88

    • 预防性, 70, 553

    • 与 554–555 相关的任务

  • Maintenance

    • adaptive, 70, 553

    • challenges of, 552

    • corrective, 69–70, 553

    • defined, 69

    • importance of, 3, 71

    • metrics for, 476

    • perfective, 70, 553

    • practice principles and, 88

    • preventive, 70, 553

    • tasks related to, 554–555

  • 制作设施,446

  • Make facilities, 446

  • 管理。另见项目管理;风险管理; 软件配置管理

    • 变化, 342, 445, 447–452

    • 复杂性,588–589

    • 配置, 11, 437, 445

    • 内容, 455, 456

    • 影响, 443, 451

    • 质量, 9, 340

    • 发布,550–551

    • 需求工程,106

    • 可重复使用性, 11

    • 安全,342

    • 供应商, 342

    • 版本,446

  • Management. see also Project management; Risk management; Software configuration management

    • change, 342, 445, 447–452

    • of complexity, 588–589

    • configuration, 11, 437, 445

    • content, 455, 456

    • impact, 443, 451

    • quality, 9, 340

    • release, 550–551

    • in requirements engineering, 106

    • reusability, 11

    • security, 342

    • vendor, 342

    • version, 446

  • 管理子系统,456–457

  • Management subsystem, 456–457

  • 中间人攻击,267

  • Man-in-the-middle attacks, 267

  • 制造商对质量的看法,311

  • Manufacturer view of quality, 311

  • 成熟度级别, 577, 578

  • Maturity levels, 577, 578

  • 成熟度模型,570–571

  • Maturity models, 570–571

  • 技术创新的成熟阶段,585

  • Maturity phase of technology innovation, 585

  • 平均故障间隔时间 (MTBF),350–351

  • Mean time between failure (MTBF), 350–351

  • 平均变更时间 (MTTC),483

  • Mean time to change (MTTC), 483

  • 测量。另请参阅指标

    • 可用性,351

    • 定义,461–462

    • 直接,479–480

    • 作为管理工具,461

    • 生产力, 480, 482

    • 可靠性,350–351

    • 安全,368–369

    • 作为伞式活动,11

    • 第 460 章、第 461 章

  • Measurement. see also Metrics

    • of availability, 351

    • defined, 461–462

    • direct, 479–480

    • as management tool, 461

    • of productivity, 480, 482

    • of reliability, 350–351

    • of security, 368–369

    • as umbrella activity, 11

    • usefulness of, 460, 461

  • 措施,定义,461

  • Measures, defined, 461

  • 会议

    • 休闲, 331

    • 看板,50

    • 问答格式,109

    • 需求收集,112

    • 评论,332–333

    • Scrum, 44–45, 56, 66–67

    • 冲刺, 44, 45

  • Meetings

    • casual, 331

    • Kanban, 50

    • question-and-answer format for, 109

    • requirements gathering, 112

    • review, 332–333

    • Scrum, 44–45, 56, 66–67

    • sprint, 44, 45

  • 熔化产品和工艺,498, 499

  • Melding product and process, 498, 499

  • 心智模型,241–242

  • Mental model, 241–242

  • 菜单标签,260

  • Menu labeling, 260

  • 元模型,443–444

  • Meta-model, 443–444

  • 隐喻, 258, 276

  • Metaphors, 258, 276

  • 元问题,109

  • Meta-questions, 109

  • 方法,9

  • Methods, 9

  • 指标

    • 美学, 472

    • 属性, 第 462 章

    • 黑匣子,466

    • 基于班级,469–470

    • 内容, 473

    • 对于传统软件,465–468

    • 定义, 462

    • 设计, 466–473, 475

    • 功能导向,481

    • 界面设计,471–473

    • 关键绩效指标,462

    • 基于 LOC,481

    • 用于维护,476

    • 对于移动应用程序,465–466

    • 形态学, 467, 468

    • 导航, 473

    • 对于面向对象的软件,468–470

    • 私人, 480, 482

    • 过程,476–478

    • 产品, 461, 463–464, 469, 480, 482

    • 生产力,481

    • 计划制定,485–487

    • 项目,476–478

    • 公共, 480

    • 质量,482–484

    • 对于需求模型,464–466

    • 评论,327–330

    • 以尺寸为导向,480–481

    • 对于小型组织,486

    • 用于软件质量保证,346

    • 对于源代码,473–474

    • 用于测试,474–475

    • 第461章 的用处

    • 对于 Web 应用程序,472, 473

  • Metrics

    • aesthetic, 472

    • attributes of, 462

    • black-box, 466

    • class-based, 469–470

    • content, 473

    • for conventional software, 465–468

    • defined, 462

    • design, 466–473, 475

    • function-oriented, 481

    • for interface design, 471–473

    • key performance indicators, 462

    • LOC-based, 481

    • for maintenance, 476

    • for MobileApps, 465–466

    • morphology, 467, 468

    • navigation, 473

    • for object-oriented software, 468–470

    • private, 480, 482

    • process, 476–478

    • product, 461, 463–464, 469, 480, 482

    • productivity, 481

    • program establishment, 485–487

    • project, 476–478

    • public, 480

    • quality, 482–484

    • for requirements model, 464–466

    • for reviews, 327–330

    • size-oriented, 480–481

    • for small organizations, 486

    • for software quality assurance, 346

    • for source code, 473–474

    • for testing, 474–475

    • usefulness of, 461

    • for WebApps, 472, 473

  • 中间件,266

  • Middleware, 266

  • 移民,574–575

  • Migration, 574–575

  • 里程碑,521

  • Milestones, 521

  • 迷你规格,112

  • Mini-specifications, 112

  • 误用案例,363–364

  • Misuse cases, 363–364

  • MobileApps(移动应用程序)

    • 敏捷变革管理,453–458

    • 警报和特殊情况,417

    • 架构,273–274

    • 设计最佳实践,285–287

    • 相关挑战,265–268

    • 组件级设计,226–227

    • 情境感知,274–275

    • 发展考虑,265

    • 手势和,415–416

    • 设计指南,271–272

    • 261、270–271 的界面设计

    • 第 423 章

    • 指标,465–466

    • 设计错误, 272

    • 模式, 292, 305–306

    • 性能,424–426

    • 264、第 264 章

    • 质量,282–285

    • 实时应用程序,426–428

    • 第424章 安全

    • 发展阶段,268–272

    • 技术考虑因素,266–268

    • 测试, 413–417, 424–428

    • 工具, 265, 267

    • 类型, 7

    • 可用性, 257, 258, 415–417

    • 虚拟键盘输入和,第416章

    • 语音输入和识别,416–417

  • MobileApps (mobile applications)

    • agile change management for, 453–458

    • alerts and extraordinary conditions, 417

    • architecture for, 273–274

    • best practices for design, 285–287

    • challenges related to, 265–268

    • component-level design for, 226–227

    • context-aware, 274–275

    • development considerations, 265

    • gestures and, 415–416

    • guidelines for design, 271–272

    • interface design for, 261, 270–271

    • internationalization of, 423

    • metrics for, 465–466

    • mistakes in design of, 272

    • patterns for, 292, 305–306

    • performance of, 424–426

    • prevalence of, 264

    • quality of, 282–285

    • real-time applications, 426–428

    • security of, 424

    • stages of development, 268–272

    • technical considerations, 266–268

    • testing, 413–417, 424–428

    • tools for, 265, 267

    • types of, 7

    • usability of, 257, 258, 415–417

    • virtual keyboard input and, 416

    • voice input and recognition, 416–417

  • 基于模型的测试 (MBT),429–430

  • Model-based testing (MBT), 429–430

  • 模型驱动的软件开发,596–597

  • Model-driven software development, 596–597

  • 模型和建模。另请参阅分析模型和建模;需求模型和建模

    • 行为,127, 149–154

    • 基于阶级的, 127, 137–146

    • 建设成本,511

    • 《儿童权利公约》,47, 144–146

    • 数据, 127

    • 设计, 93, 158, 171–178

    • 动态, 164

    • 经验估计,510–511

    • 流量导向,127

    • 框架,164

    • 功能性, 146–149, 164

    • 用于界面设计,241–242、270–271

    • 成熟期,570–571

    • 原则,92–94

    • 流程(参见流程模型)

    • 流程框架中,10

    • 产品质量,313–314

    • 使用质量,313

    • 基于情景,127, 128, 130–137

    • 安全,357–359

    • 结构,164

    • 系统方法,446

    • 威胁, 357, 365–366

    • 用户,241, 245–246

  • Models and modeling. see also Analysis models and modeling; Requirements models and modeling

    • behavioral, 127, 149–154

    • class-based, 127, 137–146

    • constructive cost, 511

    • CRC, 47, 144–146

    • data, 127

    • design, 93, 158, 171–178

    • dynamic, 164

    • empirical estimation, 510–511

    • flow-oriented, 127

    • framework, 164

    • functional, 146–149, 164

    • for interface design, 241–242, 270–271

    • maturity, 570–571

    • principles of, 92–94

    • process (see Process models)

    • in process framework, 10

    • product quality, 313–314

    • quality in use, 313

    • scenario-based, 127, 128, 130–137

    • security, 357–359

    • structural, 164

    • system approach, 446

    • threats, 357, 365–366

    • user, 241, 245–246

  • 模型-视图-控制器 (MVC) 架构,189、191–192、279–280

  • Model-View-Controller (MVC) architecture, 189, 191–192, 279–280

  • 模块化, 87, 90, 165–166

  • Modularity, 87, 90, 165–166

  • 模块,165, 209。另请参见组件

  • Modules, 165, 209. see also Components

  • 形态学指标, 467, 468

  • Morphology metrics, 467, 468

  • 多类分类问题,634

  • Multiclass classification problems, 634

  • 多标签分类问题,634

  • Multilabel classification problems, 634

  • 多重性,614

  • Multiplicity, 614

  • 导航

    • 设计,280–282

    • 菜单, 276

    • 语法, 280

    • 可见,258

  • Navigation

    • design of, 280–282

    • menus for, 276

    • syntax of, 280

    • visible, 258

  • 第665页导航节点 (NN),280

  • Page 665Navigational nodes (NN), 280

  • 导航指标,473

  • Navigation metrics, 473

  • 导航语义链接(NSL),281

  • Navigation semantic links (NSLs), 281

  • 导航语义单元(NSU),280–282

  • Navigation semantic units (NSUs), 280–282

  • 导航测试,421–423

  • Navigation testing, 421–423

  • 最近邻技术,635–637

  • Nearest neighbor technique, 635–637

  • 负面测试用例,383

  • Negative test cases, 383

  • 疏忽,320

  • Negligence, 320

  • 谈判, 23, 90, 105, 122–123

  • Negotiation, 23, 90, 105, 122–123

  • 嵌套循环,387

  • Nested loops, 387

  • 神经网络,636–637

  • Neural networks, 636–637

  • 90–90 规则,500

  • 90–90 rule, 500

  • 游牧网络,266

  • Nomadic networks, 266

  • 非功能性需求 (NFR),109

  • Nonfunctional requirements (NFRs), 109

  • 非生成模式,291

  • Nongenerative patterns, 291

  • 笔记,615

  • Notes, 615

  • 儿童数量(NOC), 469, 475

  • Number of children (NOC), 469, 475

  • 根类数量 (NOR), 475

  • Number of root classes (NOR), 475

  • 面向对象的架构,189

  • Object-oriented architectures, 189

  • 面向对象的设计指标,468–470

  • Object-oriented design metrics, 468–470

  • 面向对象测试,390–393, 404–407

  • Object-oriented testing, 390–393, 404–407

  • OO 设计指标,469–470, 475

  • OO design metrics, 469–470, 475

  • 开闭原则(OCP),212–213

  • Open-closed principle (OCP), 212–213

  • 开源运动,592

  • Open source movement, 592

  • 开放世界软件,589–590

  • Open-world software, 589–590

  • 运营,141

  • Operations, 141

  • 有序分类变量,633

  • Ordered Categorical variables, 633

  • 结对编程, 48, 332

  • Pair programming, 48, 332

  • 纸质原型, 62, 272

  • Paper prototypes, 62, 272

  • 并行流程,22, 23

  • Parallel process flow, 22, 23

  • 帕累托原则,97–98

  • Pareto principle, 97–98

  • 分区,130、389、497–498

  • Partitioning, 130, 389, 497–498

  • 被动状态,150

  • Passive state, 150

  • 基于模式的架构审查(PBAR),203–204

  • Pattern-based architecture review (PBAR), 203–204

  • 基于模式的设计

    • 常见错误,298–299

    • 在上下文中, 290, 295–296

    • 定义, 164, 290

    • 描述,293–294

    • 框架,293

    • 机器学习,294–295

    • 165 的目标

    • 整理 298、299 中的桌子

    • 存储库,295

    • 任务,297–298

    • 模板,293–294

    • 思考,296–297

    • 类型,291–293

    • 使用, 87

    • 对于用户界面,252–253

  • Pattern-based design

    • common mistakes in, 298–299

    • in context, 290, 295–296

    • defined, 164, 290

    • describing, 293–294

    • framework for, 293

    • machine learning in, 294–295

    • objectives of, 165

    • organizing tables in, 298, 299

    • repository for, 295

    • tasks in, 297–298

    • template for, 293–294

    • thinking in, 296–297

    • types of, 291–293

    • use of, 87

    • for user interfaces, 252–253

  • 模式语言,297

  • Pattern languages, 297

  • 图案整理表,298、299

  • Pattern-organizing tables, 298, 299

  • 图案。另请参阅基于模式的设计

    • 分析, 122

    • 反模式,302–304

    • 建筑, 187, 192–193, 203–204, 291, 299–300

    • 攻击,363–364

    • 行为,292–293

    • 组件级,300–301

    • 创意, 292

    • 数据,291

    • 缺陷数,98

    • 生成, 291

    • 界面设计, 252–253, 291, 304–305

    • 移动,292

    • 对于移动应用程序,292、305–306

    • 非生成性,291

    • 管道和过滤器,188

    • 过程, 24

    • 风险, 536

    • 结构,292

    • 测试, 409

    • 对于 Web 应用程序,291–292

  • Patterns. see also Pattern-based design

    • analysis of, 122

    • anti-patterns, 302–304

    • architectural, 187, 192–193, 203–204, 291, 299–300

    • attack, 363–364

    • behavioral, 292–293

    • component-level, 300–301

    • creational, 292

    • data, 291

    • of defects, 98

    • generative, 291

    • interface design, 252–253, 291, 304–305

    • mobile, 292

    • for MobileApps, 292, 305–306

    • nongenerative, 291

    • pipe-and-filter, 188

    • process, 24

    • risk, 536

    • structural, 292

    • testing, 409

    • for WebApps, 291–292

  • 同行评审,326

  • Peer reviews, 326

  • 人员能力成熟度模型,577

  • People Capability Maturity Model, 577

  • 人员能力成熟度模型(People-CMM),491

  • People Capability Maturity Model (People-CMM), 491

  • 公共和受保护的百分比 (PAP), 475

  • Percent public and protected (PAP), 475

  • 完善的维护, 70, 553

  • Perfective maintenance, 70, 553

  • 性能测试,414、424–426

  • Performance testing, 414, 424–426

  • 管道和过滤器模式,188

  • Pipe-and-filter pattern, 188

  • 规划。另请参阅项目规划

    • 意外事件, 86, 92, 544

    • 迭代, 91, 92

    • 原则,91-92

    • 流程框架中,10

    • 软件质量保证,343–344, 354

    • 用于测试,378–380

    • 在 XP 框架中,46–47

  • Planning. see also Project planning

    • contingency, 86, 92, 544

    • iterative, 91, 92

    • principles of, 91–92

    • in process framework, 10

    • for software quality assurance, 343–344, 354

    • for testing, 378–380

    • in XP framework, 46–47

  • 平台型号,270

  • Platform model, 270

  • 可玩性测试,433–434

  • Playability testing, 433–434

  • 插头点,293

  • Plug points, 293

  • 后置条件,214

  • Postconditions, 214

  • 事后评估 (PME),336

  • Postmortem evaluations (PMEs), 336

  • 实践(软件工程),12–15, 85–88

  • Practice (software engineering), 12–15, 85–88

  • 前提条件, 135, 214

  • Preconditions, 135, 214

  • 可预测的风险,535

  • Predictable risks, 535

  • 预测技术,416

  • Predictive technologies, 416

  • 准备工作,328

  • Preparation effort, 328

  • 规范性流程模型,25–33

  • Prescriptive process models, 25–33

  • 演示模型,270

  • Presentation model, 270

  • 预防成本,317

  • Prevention costs, 317

  • 预防性维护, 70, 553

  • Preventive maintenance, 70, 553

  • 主要演员,115

  • Primary actors, 115

  • 主要场景,134

  • Primary scenarios, 134

  • 原始性,468

  • Primitiveness, 468

  • 优先积分,108

  • Priority points, 108

  • 私有指标, 480, 482

  • Private metrics, 480, 482

  • 主动风险策略,534

  • Proactive risk strategies, 534

  • 主动软件支持,557–560

  • Proactive software support, 557–560

  • 概率推理,558

  • Probabilistic reasoning, 558

  • 基于问题的估计,512

  • Problem-based estimation, 512

  • 问题分解,497–498

  • Problem decomposition, 497–498

  • 问题阐述,497–498

  • Problem elaboration, 497–498

  • 解决问题,12–13

  • Problem solving, 12–13

  • 程序抽象,163

  • Procedural abstraction, 163

  • 过程。参见软件流程

  • Process. see Software process

  • 流程调整,11–12

  • Process adaptation, 11–12

  • 基于过程的估计,515–516

  • Process-based estimation, 515–516

  • 过程维度,171–172

  • Process dimension, 171–172

  • SCM 的流程要素,440

  • Process elements of SCM, 440

  • 工艺流程,22–23, 25, 31

  • Process flow, 22–23, 25, 31

  • 流程框架,10–11, 21, 23

  • Process framework, 10–11, 21, 23

  • 流程改进。参见软件流程改进

  • Process improvement. see Software process improvement

  • 处理叙述,138, 141

  • Processing narratives, 138, 141

  • 流程成熟度,570

  • Process maturity, 570

  • 流程指标,476–478

  • Process metrics, 476–478

  • 进程迁移,574

  • Process migration, 574

  • 流程模型

    • 敏捷、42–51、56、57

    • 比较,33-34

    • 批评, 38

    • 在设计中,164

    • 进化论, 29–31, 56–57, 67

    • 通用,21–23

    • 使用指南,55

    • 增量,55–56

    • 规定性的,25–33

    • 原型设计,26–29

    • 再造,563

    • 选择, 28, 31

    • 螺旋,29–30, 56–57

    • 统一,31–33

    • 瀑布, 25–26, 55

  • Process models

    • agile, 42–51, 56, 57

    • comparison of, 33–34

    • criticisms of, 38

    • in design, 164

    • evolutionary, 29–31, 56–57, 67

    • generic, 21–23

    • guidelines for use of, 55

    • incremental, 55–56

    • prescriptive, 25–33

    • prototyping, 26–29

    • reengineering, 563

    • selection of, 28, 31

    • spiral, 29–30, 56–57

    • unified, 31–33

    • waterfall, 25–26, 55

  • 流程模式,24

  • Process patterns, 24

  • 制片人, 161, 333

  • Producers, 161, 333

  • 产品,与过程的关系,34–35

  • Product, relationship to process, 34–35

  • 产品待办事项,43–45

  • Product backlog, 43–45

  • 统一流程的生产阶段,33

  • Production phase of Unified Process, 33

  • 生产力衡量标准, 480, 482

  • Productivity measures, 480, 482

  • 生产力指标,481

  • Productivity metrics, 481

  • 产品线软件, 7, 164, 590

  • Product-line software, 7, 164, 590

  • 产品指标、461、463–464、469、480、482

  • Product metrics, 461, 463–464, 469, 480, 482

  • 产品质量模型,313–314

  • Product quality model, 313–314

  • 产品请求,110–111

  • Product requests, 110–111

  • 产品范围,491–492, 497

  • Product scope, 491–492, 497

  • 产品特定风险,535–536

  • Product-specific risks, 535–536

  • 产品质量观,311

  • Product view of quality, 311

  • 渐进式签核,186

  • Progressive sign-off, 186

  • 项目复杂性,505–506

  • Project complexity, 505–506

  • 项目数据库, 441, 442, 445–446

  • Project databases, 441, 442, 445–446

  • 项目可行性,507

  • Project feasibility, 507

  • 预测,风险,538–541

  • Projection, risk, 538–541

  • 项目级别变更控制,450

  • Project level change control, 450

  • 项目管理

    • 成功的特征,500–501

    • 第502章 502

    • 491、493–496 中的人

    • 过程和, 492, 498–500

    • 产品问题,491–492、497–498

    • 为了质量,322

    • 频谱,491–492

    • W 5 HH 原则,501

  • Project management

    • characteristics for success, 500–501

    • critical practices for, 502

    • people in, 491, 493–496

    • process and, 492, 498–500

    • product issues and, 491–492, 497–498

    • for quality, 322

    • spectrum of, 491–492

    • W5HH principle for, 501

  • 第666页项目指标,476–478

  • Page 666Project metrics, 476–478

  • 项目计划。另请参见估计

    • 数据分析,509–511

    • 506 的目标

    • 概述,504

    • 流程框架中,10

    • 资源,507–509

    • 调度,520–523, 526–529

    • 第507章 507

    • 任务网络,525–526

    • 任务集,507, 523–525

  • Project planning. see also Estimation

    • data analytics in, 509–511

    • objectives of, 506

    • overview, 504

    • in process framework, 10

    • resources in, 507–509

    • scheduling in, 520–523, 526–529

    • scope and feasibility in, 507

    • task networks in, 525–526

    • task sets in, 507, 523–525

  • 项目风险,534, 536–537

  • Project risks, 534, 536–537

  • 项目规模,506

  • Project size, 506

  • 项目表,527–528

  • Project tables, 527–528

  • 项目速度,47

  • Project velocity, 47

  • 原型开发

    • 在敏捷流程模型中,56

    • 建筑设计,59-60

    • 评估, 64–65, 68–69, 253–254

    • 进化模型,67–68

    • 第一个原型建设,61–63

    • 继续、不继续的决定,65–67

    • 增量模型,55–56

    • 对于移动设备,272

    • 发布阶段,68–69

    • 范围确定,67

    • 螺旋模型,56–57

    • 利益相关者, 58–59, 61–62

    • 用户体验设计,250

  • Prototype development

    • in agile process models, 56

    • architectural design for, 59–60

    • evaluation of, 64–65, 68–69, 253–254

    • evolutionary model of, 67–68

    • first prototype construction, 61–63

    • go, no-go decisions in, 65–67

    • incremental model for, 55–56

    • for mobile devices, 272

    • release stage of, 68–69

    • scope determination in, 67

    • spiral model for, 56–57

    • stakeholders in, 58–59, 61–62

    • in user experience design, 250

  • 原型用户界面,62

  • Prototype user interface, 62

  • 原型设计范式,26–29

  • Prototyping paradigm, 26–29

  • 对数据成员的公共访问(PAD),475

  • Public access to data members (PAD), 475

  • 公共指标,480

  • Public metrics, 480

  • 发布子系统,457

  • Publishing subsystem, 457

  • Putnam-Norden-Rayleigh (PNR) 曲线,522–523

  • Putnam-Norden-Rayleigh (PNR) curve, 522–523

  • 质量

    • 清单,285

    • 代码数,345

    • 一致性,311

    • 成本,317–318

    • 311、312 的定义

    • 设计, 159–161, 282–285, 311, 345

    • 与 315–321 相关的困境

    • 加文的尺寸,311

    • “足够好”的软件,316

    • 实现准则,321-323

    • 的重要性,3

    • 遗留软件,8

    • 管理行动及其影响,321

    • 第 313 章

    • 指标,482–484

    • 移动应用程序,282–285

    • 计划, 92

    • 定性评估,314–315

    • 定量评估,315

    • 需求模型,345

    • 评论, 341–342

    • 风险和,319–320

    • 安全,以及,320

    • 标准,313–314、341、353–354

    • Web 应用程序,282–285

  • Quality

    • checklist for, 285

    • of codes, 345

    • of conformance, 311

    • cost of, 317–318

    • definitions of, 311, 312

    • of design, 159–161, 282–285, 311, 345

    • dilemmas related to, 315–321

    • Garvin’s dimensions of, 311

    • of “good enough” software, 316

    • guidelines for achievement of, 321–323

    • importance of, 3

    • of legacy software, 8

    • management actions and impact on, 321

    • McCall’s factors for, 313

    • metrics for, 482–484

    • of MobileApps, 282–285

    • planning for, 92

    • qualitative assessment of, 314–315

    • quantitative assessment of, 315

    • of requirements model, 345

    • reviews for, 341–342

    • risk and, 319–320

    • security and, 320

    • standards for, 313–314, 341, 353–354

    • of WebApps, 282–285

  • 质量保证,11, 323, 353。另请参见软件质量保证

  • Quality assurance, 11, 323, 353. see also Software quality assurance

  • 质量控制,322–323, 346

  • Quality control, 322–323, 346

  • 质量困境,315–321

  • Quality dilemma, 315–321

  • 使用质量模型,313

  • Quality in use model, 313

  • 质量管理,9, 340, 349。另请参见软件质量保证

  • Quality management, 9, 340, 349. see also Software quality assurance

  • 质量要求树,283

  • Quality requirements tree, 283

  • 问答环节,109

  • Question-and-answer sessions, 109

  • 反应性风险策略,533

  • Reactive risk strategies, 533

  • 可读性, 258, 431

  • Readability, 258, 431

  • 实时测试,426–428

  • Real-time testing, 426–428

  • 估计的核对,518-519

  • Reconciliation of estimates, 518–519

  • 录音机, 161, 333

  • Recorders, 161, 333

  • 记录保存,333–334、378–380

  • Recordkeeping, 333–334, 378–380

  • 恢复测试,417

  • Recovery testing, 417

  • 再造,554, 562–565

  • Reengineering, 554, 562–565

  • 重构

    • 建筑,561–562

    • 代码, 561, 564

    • 组件,230–231

    • 数据, 561, 564–565

    • 定义, 48, 554, 560

    • 设计, 48, 168, 225

    • 接口,221

    • 工具, 230, 561

  • Refactoring

    • architecture, 561–562

    • code, 561, 564

    • components, 230–231

    • data, 561, 564–565

    • defined, 48, 554, 560

    • design, 48, 168, 225

    • interfaces, 221

    • tools for, 230, 561

  • 细化

    • 风险,542–543

    • 逐步, 167–168, 248

    • 任务集,524–525

  • Refinement

    • of risk, 542–543

    • stepwise, 167–168, 248

    • of task sets, 524–525

  • 回归问题,634

  • Regression problems, 634

  • 回归测试,68, 403–404

  • Regression testing, 68, 403–404

  • 发布管理,550–551

  • Release management, 550–551

  • 发布重用等效原则 (REP),214–215

  • Release reuse equivalency principle (REP), 214–215

  • 可靠性,350–353

  • Reliability, 350–353

  • 远程过程调用架构,189

  • Remote procedure call architectures, 189

  • 技术创新的复制阶段,585

  • Replicator phase of technology innovation, 585

  • 报告,333–334、402、448、452、458

  • Reporting, 333–334, 402, 448, 452, 458

  • 存储库,295、441、443–446

  • Repositories, 295, 441, 443–446

  • 表示状态转移(REST),273

  • Representation State Transfer (REST), 273

  • 要求

    • 分析,127–130

    • 建筑设计和,59–60

    • 合作,108

    • 紧急情况,590–591

    • 监控,123

    • 多种观点,107–108

    • 谈判,122–123

    • 无功能,109

    • 测试用例,382–383

    • 追踪,445

    • 理解,102–103

    • 验证,123–124

  • Requirements

    • analysis of, 127–130

    • architectural design and, 59–60

    • collaboration on, 108

    • emergent, 590–591

    • monitoring, 123

    • multiple viewpoints on, 107–108

    • negotiating, 122–123

    • nonfunctional, 109

    • test cases for, 382–383

    • tracing, 445

    • understanding, 102–103

    • validation of, 123–124

  • 需求工程

    • 敏捷, 58, 104

    • 定义, 57, 103

    • 第 108–109 节中的第一个问题

    • 以目标为导向,104

    • 为了安全,360–363

    • 规格, 105, 407

    • 任务,104–106

    • 对于技术,596

    • 可追溯性,109–110

  • Requirements engineering

    • agile, 58, 104

    • defined, 57, 103

    • first questions in, 108–109

    • goal-oriented, 104

    • for security, 360–363

    • specifications in, 105, 407

    • tasks in, 104–106

    • for technology, 596

    • traceability in, 109–110

  • 需求收集,24, 110–114。另见启发

  • Requirements gathering, 24, 110–114. see also Elicitation

  • 需求模型和建模。另请参见分析模型和建模

    • 行为,127, 149–154

    • 基于阶级的, 127, 137–146

    • 的域,93

    • 功能性,146–149

    • 指标,464–466

    • 目标和理念,128

    • 原则,129–130

    • 质量, 345

    • 经验法则,128–129

    • 基于情景,127, 128, 130–137

    • 术语,126

    • 转化为设计模型,158

    • 类型, 127

  • Requirements models and modeling. see also Analysis models and modeling

    • behavioral, 127, 149–154

    • class-based, 127, 137–146

    • domains of, 93

    • functional, 146–149

    • metrics for, 464–466

    • objectives and philosophy of, 128

    • principles of, 129–130

    • quality of, 345

    • rules of thumb for, 128–129

    • scenario-based, 127, 128, 130–137

    • terminology for, 126

    • translation into design model, 158

    • types of, 127

  • 要求质量,345

  • Requirements quality, 345

  • 需求任务

    • 详细阐述,104–105

    • 启发, 104, 109

    • 起始,104

    • 管理,106

    • 谈判, 105, 122–123

    • 规格,105

    • 验证, 105–106, 123–124

  • Requirements tasks

    • elaboration, 104–105

    • elicitation, 104, 109

    • inception, 104

    • management, 106

    • negotiation, 105, 122–123

    • specification, 105

    • validation, 105–106, 123–124

  • 资源

    • 环境,509

    • 估计, 60–61, 505

    • 人类,508

    • 在项目规划中,507–509

    • 可重复使用,509

  • Resources

    • environmental, 509

    • estimation of, 60–61, 505

    • human, 508

    • in project planning, 507–509

    • reusable, 509

  • 类响应 (RFC),470

  • Response for a class (RFC), 470

  • 响应时间,259

  • Response time, 259

  • CRC 建模中的职责,144

  • Responsibilities, in CRC modeling, 144

  • 责任驱动架构(RDA),186

  • Responsibility-driven architecture (RDA), 186

  • 重组,564

  • Restructuring, 564

  • 投资回报率(ROI),580

  • Return on investment (ROI), 580

  • 可重用性管理,11

  • Reusability management, 11

  • 可重用的软件资源,509

  • Reusable software resources, 509

  • 重复使用, 214–215, 228, 229

  • Reuse, 214–215, 228, 229

  • 逆向工程,553–557, 564

  • Reverse engineering, 553–557, 564

  • 审查工作,328

  • Review effort, 328

  • 审查问题列表,333–334

  • Review issues list, 333–334

  • 审核领导者、161、333

  • Review leaders, 161, 333

  • 审查会议,332–333

  • Review meetings, 332–333

  • 评论。另请参阅技术评论

    • 敏捷,336

    • 建筑,202–204

    • 休闲, 326, 331

    • 第667页清单,331

    • 办公桌检查,331–332

    • 正式,327, 332–335

    • 指南,334–335

    • 非正式,331–332

    • 检查, 326, 332

    • 指标,327–330

    • 同行,326

    • 目的,325

    • 质量,341–342

    • 报告和记录保存,333–334

    • 演练, 326, 332

  • Reviews. see also Technical reviews

    • agile, 336

    • architectural, 202–204

    • casual, 326, 331

    • Page 667checklists for, 331

    • desk checks, 331–332

    • formal, 327, 332–335

    • guidelines for, 334–335

    • informal, 331–332

    • inspections, 326, 332

    • metrics for, 327–330

    • peer, 326

    • purpose of, 325

    • for quality, 341–342

    • reporting and recordkeeping for, 333–334

    • walkthroughs, 326, 332

  • 返工工作,328

  • Rework effort, 328

  • 风险。另见风险评估;风险管理

    • 商业, 534

    • 分类,534–535

    • 第534章 的特点

    • 基于组件的软件工程,229

    • 的组成部分, 537

    • 537 的司机

    • 估计,538–541

    • 暴露于,540–541

    • 通用,535

    • 识别,535–537

    • 的影响,540–541

    • 已知,535

    • 低质量的软件,以及,319–320

    • 第 536 章

    • 可预测的,535

    • 产品特定,535–536

    • 项目, 534, 536–537

    • 细化,542–543

    • 技术, 534

    • 不可预测,535

  • Risk. see also Risk assessment; Risk management

    • business, 534

    • categorization of, 534–535

    • characteristics of, 534

    • in component-based software engineering, 229

    • components of, 537

    • drivers of, 537

    • estimation of, 538–541

    • exposure to, 540–541

    • generic, 535

    • identification of, 535–537

    • impact of, 540–541

    • known, 535

    • low-quality software and, 319–320

    • patterns of, 536

    • predictable, 535

    • product-specific, 535–536

    • project, 534, 536–537

    • refinement of, 542–543

    • technical, 534

    • unpredictable, 535

  • 风险评估

    • 集体,539

    • 应急计划,以及,86

    • 在原型开发中,66

    • 安全, 362, 364–365

    • 螺旋模型,30, 56, 57

  • Risk assessment

    • collective, 539

    • contingency plans and, 86

    • in prototype development, 66

    • security, 362, 364–365

    • in spiral model, 30, 56, 57

  • 风险信息表 (RIS), 546, 547

  • Risk information sheet (RIS), 546, 547

  • 风险项目清单,536

  • Risk item checklists, 536

  • 风险管理

    • 框架,364–365

    • 游戏化,544–545

    • 故意的,533

    • 第535章

    • 积极主动的策略,534

    • 反应策略,533

    • RMMM 计划,546

    • 用于软件流程改进,575–576

    • 在软件质量保证方面,342

    • 作为伞式活动,11

  • Risk management

    • framework for, 364–365

    • gamification and, 544–545

    • intentional, 533

    • principles of, 535

    • proactive strategies, 534

    • reactive strategies, 533

    • RMMM plan for, 546

    • for software process improvement, 575–576

    • in software quality assurance, 342

    • as umbrella activity, 11

  • 风险缓解、监控和管理 (RMMM), 539, 543–547

  • Risk Mitigation, Monitoring, and Management (RMMM), 539, 543–547

  • 以风险为导向的决策,321

  • Risk-oriented decisions, 321

  • 风险预测,538–541

  • Risk projection, 538–541

  • 风险表,538–539

  • Risk tables, 538–539

  • 运行时验证,123

  • Run-time validation, 123

  • 运行时验证,123

  • Run-time verification, 123

  • 安全之家

    • 活动图, 147, 152

    • 应用 CK 指标,471

    • 应用模式,301–302

    • 原型,197–198

    • 建筑评估,202

    • 建筑背景图,197

    • 行为建模,121

    • 选择建筑风格,192

    • 级别型号,142

    • 班级测试,391

    • 行动中的凝聚力,217–218

    • 沟通错误,90

    • 结论,604

    • 考虑敏捷软件开发,43

    • 考虑第一个原型,63

    • 控制面板,115–117

    • 耦合作用,219

    • CRC 模型,145–146

    • 争论产品指标,464

    • 设计课程,171

    • 设计概念,168–169

    • 设计独特的测试,382

    • 设计模式,292–293

    • 设计与编码,159

    • 建立衡量方法,479

    • 估计,513–514

    • 评估架构决策,194–195

    • 评估第一个原型,65

    • 制定移动设备要求,269–270

    • 游戏化和风险管理,545–546

    • 语法分析,138

    • 平面设计,237

    • 实例化,200

    • 界面设计审查,254–255

    • 基于指标的质量方法,484

    • 迷你规格,112

    • 谈判,122–123

    • 开闭原则的实际应用,213

    • 整体建筑结构,199–200

    • 准备测试,377

    • 准备验证,408

    • 产品请求,111

    • 质量保证,345

    • 质量问题, 319, 335

    • 回归测试,403–404

    • 需求收集会议,112

    • 风险分析,541–542

    • SCM 问题,451

    • 选择过程模型,28, 31

    • 序列图,148

    • 启动项目,16

    • 状态图,151

    • 泳道图,153

    • 团队结构, 79, 496

    • 跟踪日程安排,529

    • 用例图, 118, 119, 137

    • 用户界面设计的用例,247

    • 用例模板,135–136

    • 用户场景,113–114, 132–133

    • 使用圈复杂度,386

    • 违反界面黄金规则,240

    • Web 应用程序测试,419–420

  • SafeHome

    • activity diagram, 147, 152

    • applying CK metrics, 471

    • applying patterns, 301–302

    • archetypes, 197–198

    • architectural assessment, 202

    • architectural context diagram, 197

    • behavioral modeling, 121

    • choosing an architectural style, 192

    • class models, 142

    • class testing, 391

    • cohesion in action, 217–218

    • communication mistakes, 90

    • conclusion, 604

    • considering agile software development, 43

    • considering first prototype, 63

    • control panel, 115–117

    • coupling in action, 219

    • CRC models, 145–146

    • debating product metrics, 464

    • design classes, 171

    • design concepts, 168–169

    • designing unique tests, 382

    • design patterns, 292–293

    • design vs. coding, 159

    • establishing a metrics approach, 479

    • estimating, 513–514

    • evaluating architectural decisions, 194–195

    • evaluating first prototype, 65

    • formulating mobile device requirements, 269–270

    • gamification and risk management, 545–546

    • grammatical parse, 138

    • graphic design, 237

    • instantiations of, 200

    • interface design review, 254–255

    • metrics-based quality approach, 484

    • mini-specifications, 112

    • negotiation, 122–123

    • open-closed principle in action, 213

    • overall architectural structure, 199–200

    • preparing for testing, 377

    • preparing for validation, 408

    • product request, 111

    • quality assurance, 345

    • quality issues, 319, 335

    • regression testing, 403–404

    • requirements gathering meeting, 112

    • risk analysis, 541–542

    • SCM issues, 451

    • selecting process model, 28, 31

    • sequence diagram, 148

    • starting projects, 16

    • state diagram, 151

    • swimlane diagram, 153

    • team structure, 79, 496

    • tracking the schedule, 529

    • use case diagram, 118, 119, 137

    • use cases for user interface design, 247

    • use case template, 135–136

    • user scenario, 113–114, 132–133

    • using cyclomatic complexity, 386

    • violating interface golden rules, 240

    • WebApp testing, 419–420

  • 安全考虑,342、352–353、545

  • Safety considerations, 342, 352–353, 545

  • 脚手架, 64, 379

  • Scaffolding, 64, 379

  • 基于场景的元素,119

  • Scenario-based elements, 119

  • 基于场景的建模

    • 演员和用户资料,131

    • 的特征,127

    • 概述,130

    • 受欢迎程度, 128

    • 用例,131–137

  • Scenario-based modeling

    • actors and user profiles in, 131

    • characteristics of, 127

    • overview, 130

    • popularity of, 128

    • use cases in, 131–137

  • 基于场景的测试,407

  • Scenario-based testing, 407

  • 日程安排, 321, 520–523, 526–529

  • Scheduling, 321, 520–523, 526–529

  • 科学软件,7

  • Scientific software, 7

  • 范围

    • 产品数量, 491–492, 497

    • 项目数, 91, 114

    • 原型开发中,67

    • 软件, 497, 507

    • 用例,135

    • 用户体验设计,234

  • Scope

    • of products, 491–492, 497

    • of projects, 91, 114

    • in prototype development, 67

    • of software, 497, 507

    • of use cases, 135

    • of user experience design, 234

  • Scrum 框架,42–45, 56, 66–67

  • Scrum framework, 42–45, 56, 66–67

  • 基于搜索的软件工程 (SBSE), 161, 558, 597, 638

  • Search-based software engineering (SBSE), 161, 558, 597, 638

  • 次要演员,115

  • Secondary actors, 115

  • 次要场景,134

  • Secondary scenarios, 134

  • 安全编码,367

  • Secure coding, 367

  • 安全

    • 攻击模式和,363–364

    • 攻击面,366–367

    • 编码和,367–368

    • 356、357 的重要性

    • 在完整性测量中,483

    • 生命周期模型,357–359

    • 管理, 342

    • 测量,368–369

    • 误用和滥用案例,363–364

    • 移动应用程序数量,424

    • 流程改进和成熟度模型,370

    • 质量和,320

    • 需求工程,360–363

    • 风险评估, 362, 364–365

    • 测试, 414, 423–424

    • 威胁建模方法,365–366

    • 工具, 358, 365

    • 接触点,359

    • Web 应用程序数量,424

  • Security

    • attack patterns and, 363–364

    • attack surface and, 366–367

    • coding and, 367–368

    • importance of, 356, 357

    • in integrity measurement, 483

    • life-cycle models for, 357–359

    • management of, 342

    • measurement of, 368–369

    • misuse and abuse cases, 363–364

    • of MobileApps, 424

    • process improvement and maturity models, 370

    • quality and, 320

    • requirements engineering for, 360–363

    • risk assessment, 362, 364–365

    • testing, 414, 423–424

    • threat modeling methods, 365–366

    • tools for, 358, 365

    • touchpoints for, 359

    • of WebApps, 424

  • 安全开发生命周期 (SDL), 357–359, 365

  • Security Development Lifecycle (SDL), 357–359, 365

  • 选择和论证活动,573–574

  • Selection and justification activity, 573–574

  • 第668页选择性测试,381

  • Page 668Selective testing, 381

  • 自组织团队, 41, 45, 78, 86, 495

  • Self-organizing teams, 41, 45, 78, 86, 495

  • 语义测试,420–421

  • Semantic testing, 420–421

  • 敏感点,201

  • Sensitivity points, 201

  • 关注点分离、87、130、165、194

  • Separation of concerns, 87, 130, 165, 194

  • 序列图,148–149, 618–621

  • Sequence diagrams, 148–149, 618–621

  • 服务器类,404

  • Server classes, 404

  • 服务计算,273

  • Service computing, 273

  • 面向服务的架构决策 (SOAD),195–196

  • Service-oriented architecture decision (SOAD), 195–196

  • 收缩包装,342

  • Shrink-wrapped packages, 342

  • 简单对象访问协议(SOAP),273

  • Simple Object Access Protocol (SOAP), 273

  • 六西格码, 9, 349

  • Six Sigma, 9, 349

  • 以规模为导向的指标,480–481

  • Size-oriented metrics, 480–481

  • 老虎机,293

  • Slots, 293

  • 烟雾测试,400–401

  • Smoke testing, 400–401

  • 社交媒体, 79–80, 559, 604

  • Social media, 79–80, 559, 604

  • 社交网络工具,79

  • Social networking tools, 79

  • 软件

    • 应用领域, 7

    • 构建模块,591–592

    • 签约, 342

    • 定义, 5

    • 失效曲线,6

    • “足够好,”316

    • 2-3 的重要性 603

    • 有关的关键问题,4

    • 遗产, 8

    • 模型驱动的开发,596–597

    • 性质, 4–8, 74

    • 开放世界,589–590

    • 产品线软件, 7, 164, 590

    • 与 3 有关的现实

    • 可靠性,350–353

    • 安全, 342, 352–353, 545

  • Software

    • application domains, 7

    • building blocks for, 591–592

    • contracted, 342

    • defined, 5

    • failure curves for, 6

    • “good enough,” 316

    • importance of, 2–3, 603

    • key questions regarding, 4

    • legacy, 8

    • model-driven development of, 596–597

    • nature of, 4–8, 74

    • open-world, 589–590

    • product-line software, 7, 164, 590

    • realities related to, 3

    • reliability of, 350–353

    • safety of, 342, 352–353, 545

  • 软件分析,462–463, 558–559

  • Software analytics, 462–463, 558–559

  • 软件架构。参见架构

  • Software architecture. see Architecture

  • 软件保障成熟度模型 (SAMM),370

  • Software Assurance Maturity Model (SAMM), 370

  • 软件资本,20

  • Software capital, 20

  • 软件组件。参见组件

  • Software components. see Components

  • 软件配置,已定义,438

  • Software configuration, defined, 438

  • 软件配置审核,452

  • Software configuration audits, 452

  • 软件配置项 (SCI)、438、441–442

  • Software configuration items (SCIs), 438, 441–442

  • 软件配置管理(SCM)

    • 441、442、450 中的基线

    • 持续集成,446–447

    • 依赖和变化,442–443

    • 元素, 440

    • 存储库, 441, 443–446

    • 情景,439–440

    • 涉及的任务,447–448

    • 版本控制系统,445–446

    • 工作流程,438

  • Software configuration management (SCM)

    • baselines in, 441, 442, 450

    • continuous integration and, 446–447

    • of dependencies and changes, 442–443

    • elements of, 440

    • repository for, 441, 443–446

    • scenario for, 439–440

    • tasks involved in, 447–448

    • version control systems, 445–446

    • work flow for, 438

  • 软件缺陷。参见缺陷

  • Software defects. see Defects

  • 软件设计。参见设计

  • Software design. see Design

  • 软件工程。另请参阅软件工程趋势

    • 基于组件,228–230, 509

    • 计算机辅助,9

    • 定义, 8

    • 作为纪律,585–586

    • 道德和,607–609

    • 目标, 438

    • 重大挑战,594–595

    • 智能,606

    • 层数,9

    • 远景,606–607

    • 练习, 12–15, 85–88

    • 原则, 14–15, 85–100

    • 心理学, 75–76

    • 基于搜索、161、558、597、638

    • 社交媒体,79–80

    • 项目启动,15-16

    • 视频游戏,1–2

  • Software engineering. see also Trends in software engineering

    • component-based, 228–230, 509

    • computer-aided, 9

    • defined, 8

    • as discipline, 585–586

    • ethics and, 607–609

    • goals of, 438

    • grand challenge for, 594–595

    • intelligent, 606

    • layers of, 9

    • long view of, 606–607

    • practice, 12–15, 85–88

    • principles of, 14–15, 85–100

    • psychology of, 75–76

    • search-based, 161, 558, 597, 638

    • social media and, 79–80

    • start of projects, 15–16

    • video games, 1–2

  • 软件工程环境 (SEE), 509, 599–600

  • Software engineering environment (SEE), 509, 599–600

  • 软件工程师,75、84

  • Software engineers, 75, 84

  • 软件方程,523

  • Software equation, 523

  • 软件演化,550, 562–565

  • Software evolution, 550, 562–565

  • 软件增量,11、32、40、58

  • Software increments, 11, 32, 40, 58

  • 软件维护。参见维护

  • Software maintenance. see Maintenance

  • 软件成熟度指数 (SMI),476

  • Software maturity index (SMI), 476

  • 软件测量。参见测量

  • Software measurement. see Measurement

  • 软件平台解决方案,592

  • Software platform solutions, 592

  • 软件流程

    • 改编,11-12

    • 敏捷性和(参见敏捷性)

    • 评估和改进,24-25

    • 9–10 的组成部分

    • 分解, 498–500

    • 定义, 9, 20, 21

    • 流量, 22–23, 25, 31

    • 框架, 10–11, 21, 23

    • 模型(参见过程模型)

    • 指导原则,85–86

    • 项目管理和, 492, 498–500

    • 推荐步骤,71

    • 与产品的关系,34–35

    • 示意图,21

    • 相关趋势,593–594

  • Software process

    • adaptation of, 11–12

    • agility and (see Agility)

    • assessment and improvement of, 24–25

    • components of, 9–10

    • decomposition of, 498–500

    • defined, 9, 20, 21

    • flow of, 22–23, 25, 31

    • framework for, 10–11, 21, 23

    • models for (see Process models)

    • principles guiding, 85–86

    • project management and, 492, 498–500

    • recommended steps, 71

    • relationship to product, 34–35

    • schematic representation of, 21

    • trends related to, 593–594

  • 软件过程改进(SPI)

    • 评估和差距分析,572–573

    • 连续,341

    • 教育和培训,573

    • 评估, 575

    • 框架, 569–570, 576–579

    • 安装/迁移,574–575

    • 成熟度模型,570–571

    • 投资回报率,580

    • 风险管理,575–576

    • 第370章

    • 选择和理由,573–574

    • 对于小型组织,571

    • 步骤,571–576

    • 趋势, 580–581

  • Software process improvement (SPI)

    • assessment and gap analysis in, 572–573

    • continuous, 341

    • education and training in, 573

    • evaluation in, 575

    • frameworks for, 569–570, 576–579

    • installation/migration in, 574–575

    • maturity models for, 570–571

    • return on investment, 580

    • risk management for, 575–576

    • security and, 370

    • selection and justification in, 573–574

    • for small organizations, 571

    • steps for, 571–576

    • trends in, 580–581

  • 软件流程重新设计(SPR),574

  • Software process redesign (SPR), 574

  • 软件产品线, 7, 164

  • Software product lines, 7, 164

  • 软件项目计划。参见项目规划

  • Software project plans. see Project planning

  • 软件质量保证(SQA)

    • 属性,346

    • 相关背景问题,341

    • 340–343 的元素

    • 第347章

    • 目标,345–346

    • 指标,346

    • 计划, 343–344, 354

    • 工艺和产品特性,343

    • 可靠性,350–353

    • 安全, 342, 352–353

    • 六西格码 9, 349

    • 统计, 347–349, 378

    • 任务,343–344

  • Software quality assurance (SQA)

    • attributes in, 346

    • background issues related to, 341

    • elements of, 340–343

    • formal approaches to, 347

    • goals of, 345–346

    • metrics for, 346

    • plans for, 343–344, 354

    • processes and product characteristics, 343

    • reliability, 350–353

    • safety, 342, 352–353

    • Six Sigma for, 9, 349

    • statistical, 347–349, 378

    • tasks of, 343–344

  • 软件再造,554, 562–565

  • Software reengineering, 554, 562–565

  • 软件评论。查看评论

  • Software reviews. see Reviews

  • 软件范围, 497, 507

  • Software scope, 497, 507

  • 软件安全。参见安全性

  • Software security. see Security

  • 软件规模调整,511

  • Software sizing, 511

  • 软件支持。另请参见维护

    • 分析,558–559

    • 成本, 559–560

    • 549、550 的元素

    • 迭代模型,551

    • 积极主动,557–560

    • 社交媒体,以及,559

  • Software support. see also Maintenance

    • analytics in, 558–559

    • cost of, 559–560

    • elements of, 549, 550

    • iterative model of, 551

    • proactive, 557–560

    • social media and, 559

  • 软件团队。查看团队

  • Software teams. see Teams

  • 源代码分析,561

  • Source code analysis, 561

  • 源代码指标,473–474

  • Source code metrics, 473–474

  • 源对象,251

  • Source objects, 251

  • 间距,194

  • Spacing, 194

  • 规格

    • 在沟通活动中,23

    • 迷你规格,112

    • 需求工程,105, 407

    • 模板,105

    • 测试,402

  • Specifications

    • in communication activity, 23

    • mini-specifications, 112

    • in requirements engineering, 105, 407

    • template for, 105

    • test, 402

  • SPICE 模型,579

  • SPICE model, 579

  • 螺旋模型,29–30、56–57

  • Spiral model, 29–30, 56–57

  • 冲刺、42–45、61、186

  • Sprints, 42–45, 61, 186

  • SQA 小组,341、343–344

  • SQA groups, 341, 343–344

  • 方形过程,360–363

  • SQUARE process, 360–363

  • 利益相关者

    • 108 之间的合作

    • 与 23、24 沟通

    • 定义, 10, 107

    • 来自 27、45、55 的反馈

    • 识别, 107

    • 与 122 谈判

    • 规划中,91

    • 项目管理,493

    • 原型开发,58–59, 61–62

  • Stakeholders

    • collaboration among, 108

    • communication with, 23, 24

    • defined, 10, 107

    • feedback from, 27, 45, 55

    • identifying, 107

    • negotiation with, 122

    • in planning, 91

    • in project management, 493

    • in prototype development, 58–59, 61–62

  • 第669页质量标准,313–314、341、353–354

  • Page 669Standards for quality, 313–314, 341, 353–354

  • 状态,定义,120

  • State, defined, 120

  • 状态图,224

  • Statecharts, 224

  • 状态图, 120–121, 150–151, 392, 625–628

  • State diagrams, 120–121, 150–151, 392, 625–628

  • 静态分析工具,368

  • Static analysis tools, 368

  • 静态架构一致性分析(SACA),204

  • Static architecture-conformance analysis (SACA), 204

  • 静态测试,429

  • Static testing, 429

  • 统计质量保证,347–349, 378

  • Statistical quality assurance, 347–349, 378

  • 统计软件流程改进(SSPI),478

  • Statistical software process improvement (SSPI), 478

  • 状态报告,452

  • Status reporting, 452

  • 逐步细化,167–168, 248

  • Stepwise refinement, 167–168, 248

  • 刻板印象,613

  • Stereotypes, 613

  • 故事板,186

  • Storyboarding, 186

  • 压力测试,425–426

  • Stress testing, 425–426

  • STRIDE 型号、365、366

  • STRIDE model, 365, 366

  • 结构复杂性,467

  • Structural complexity, 467

  • 结构模型,164

  • Structural models, 164

  • 结构模式,292

  • Structural patterns, 292

  • 结构特性,164

  • Structural properties, 164

  • 结构测试, 97, 383–387, 397

  • Structural testing, 97, 383–387, 397

  • 结构不确定性,506

  • Structural uncertainty, 506

  • 结构图,210

  • Structure charts, 210

  • 结构化分析,128

  • Structured analysis, 128

  • 存根,379

  • Stubs, 379

  • 充足性,468

  • Sufficiency, 468

  • 监督学习,634

  • Supervised learning, 634

  • 可支持性,552。另请参见软件支持

  • Supportability, 552. see also Software support

  • 泳道图,151, 153–154

  • Swimlane diagrams, 151, 153–154

  • 对称性,194

  • Symmetry, 194

  • 同步控制,450

  • Synchronization control, 450

  • 系统复杂性,467

  • System complexity, 467

  • 系统耦合,129

  • System coupling, 129

  • 系统建模,446

  • System modeling, 446

  • 力量系统,290

  • System of forces, 290

  • 系统软件,7

  • System software, 7

  • 系统测试、376、377、396

  • System testing, 376, 377, 396

  • 定制外壳,342

  • Tailored shell, 342

  • 人才组合,591

  • Talent mix, 591

  • 目标环境,509

  • Target environment, 509

  • 目标物体,251

  • Target objects, 251

  • 任务,已定义,10

  • Task, defined, 10

  • 任务分析,243, 247–248

  • Task analysis, 243, 247–248

  • 任务模型,270

  • Task model, 270

  • 任务网络,525–526

  • Task networks, 525–526

  • 任务集

    • 通讯, 23, 24, 500

    • 概念开发项目,524

    • 定义, 21

    • 设计, 162

    • 项目规划,507, 523–525

    • 细化,524–525

  • Task sets

    • communication, 23, 24, 500

    • concept development projects, 524

    • defined, 21

    • design, 162

    • project planning, 507, 523–525

    • refinement of, 524–525

  • 团队

    • 敏捷、40、41、78、495

    • 第587章

    • 协调和沟通,496, 604

    • 发展, 43–45, 67

    • 全球,80–81

    • 胶凝, 76–77, 494

    • 看板,48–50

    • 领导人, 493–494

    • 项目管理,494–496

    • Scrum, 43, 44

    • 自组织, 41, 45, 78, 86, 495

    • 结构, 78–79, 496

    • 第591章 人才组合

    • 毒性, 77, 495

  • Teams

    • agile, 40, 41, 78, 495

    • collaboration and, 587

    • coordination and communication, 496, 604

    • development, 43–45, 67

    • global, 80–81

    • jelled, 76–77, 494

    • Kanban, 48–50

    • leaders of, 493–494

    • in project management, 494–496

    • Scrum, 43, 44

    • self-organizing, 41, 45, 78, 86, 495

    • structure of, 78–79, 496

    • talent mix and, 591

    • toxicity of, 77, 495

  • 技术债务、157、230、327、533

  • Technical debt, 157, 230, 327, 533

  • 技术审查 (TR)

    • 第 329 章

    • 标准,330–331

    • 设计质量, 160, 161

    • 正式,327, 332–335

    • 非正式,331–332

    • 目的,326

    • 质量,341–342

    • 参考模型,330

    • 对于需求验证,105–106

    • 作为伞式活动,11

  • Technical reviews (TRs)

    • cost effectiveness of, 329

    • criteria for, 330–331

    • of design quality, 160, 161

    • formal, 327, 332–335

    • informal, 331–332

    • purpose of, 326

    • for quality, 341–342

    • reference model for, 330

    • for requirements validation, 105–106

    • as umbrella activity, 11

  • 技术风险,534

  • Technical risks, 534

  • 技术

    • 协作开发,595–596

    • 创新,584–585

    • 预测,416

    • 流程趋势,593–594

    • 需求工程,596

  • Technology

    • collaborative development of, 595–596

    • innovations in, 584–585

    • predictive, 416

    • process trends, 593–594

    • requirements engineering for, 596

  • 模板

    • 基于模式的设计,293–294

    • 供出版,457

    • 用于软件测试,373

    • 规格,105

    • 用于系统建模,446

    • 用例,135–136

  • Templates

    • for pattern-based design, 293–294

    • for publication, 457

    • for software testing, 373

    • for specifications, 105

    • for system modeling, 446

    • use case, 135–136

  • 测试用例设计,381–383、405–407

  • Test case design, 381–383, 405–407

  • 测试驱动开发 (TDD),598–599

  • Test-driven development (TDD), 598–599

  • 测试框架,62

  • Test frames, 62

  • 测试。另请参阅组件级测试;集成级测试

    • 接受, 48, 68–69, 95, 430

    • 无障碍,432–433

    • 在敏捷流程中,95

    • 警报和特殊情况,417

    • 阿尔法,430

    • 建筑, 375, 376

    • 人工智能系统,428–429

    • 基本路径,384–386

    • 行为,388–390, 392–393

    • 贝塔,430

    • 黑匣子, 388–390, 397

    • 边界,381–382

    • 认证,414

    • 班级,390–391

    • 基于云,428

    • 集群,404

    • 状况, 386

    • 连接性,414

    • 内容,420–421

    • 控制结构,386–387

    • 性价比,379–380

    • “完成”的标准,377-378

    • 数据流, 381, 386

    • 文档,434

    • 动态, 429

    • 详尽,380

    • 基于故障,405–406

    • 功能性, 97, 388–390, 397

    • 手势,415–416

    • 玻璃盒, 383–387, 397

    • 帮助设施,434

    • 高阶,377

    • 接口, 388, 421

    • 循环,387

    • 指标,474–475

    • 移动应用程序, 413–417, 424–428

    • 基于模型,429–430

    • 导航,421–423

    • 面向对象, 390–393, 404–407

    • 组织,374–375

    • 图案, 409

    • 性能, 414, 424–426

    • 可玩性,433–434

    • 准备, 377

    • 96-98 的原则

    • 原型,63–65、68–69

    • 为了质量,342

    • 实时,426–428

    • 恢复, 417

    • 回归, 68, 403–404

    • 基于场景,407

    • 安全, 414, 423–424

    • 选择性, 381

    • 语义,420–421

    • 烟雾,400–401

    • 螺旋图,375–376

    • 静态,429

    • 步骤,376–377

    • 结构, 97, 383–387, 397

    • 系统, 376, 377, 396

    • 基于线程,404

    • 工具, 50, 413, 415, 422, 430

    • 单元, 48, 95, 376, 378–381

    • 可用性, 415–417, 430–432

    • 基于使用,404

    • 用户,255–256

    • 用户体验,414–417

    • 验证, 95, 373–377, 407–408

    • 验证,373–374

    • 虚拟环境,430–434

    • 虚拟键盘输入,416

    • 语音输入和识别,416–417

    • 网络应用程序,418–426

    • 白盒, 383–387, 397

  • Testing. see also Component-level testing; Integration-level testing

    • acceptance, 48, 68–69, 95, 430

    • accessibility, 432–433

    • in agile processes, 95

    • alerts and extraordinary conditions, 417

    • alpha, 430

    • architecture, 375, 376

    • artificial intelligence systems, 428–429

    • basis path, 384–386

    • behavioral, 388–390, 392–393

    • beta, 430

    • black-box, 388–390, 397

    • boundary, 381–382

    • certification, 414

    • class, 390–391

    • cloud-based, 428

    • cluster, 404

    • condition, 386

    • connectivity, 414

    • content, 420–421

    • control structure, 386–387

    • cost-effective, 379–380

    • criteria for “done,” 377–378

    • data flow, 381, 386

    • documentation, 434

    • dynamic, 429

    • exhaustive, 380

    • fault-based, 405–406

    • functional, 97, 388–390, 397

    • gesture, 415–416

    • glass-box, 383–387, 397

    • help facilities, 434

    • high-order, 377

    • interface, 388, 421

    • loop, 387

    • metrics for, 474–475

    • MobileApps, 413–417, 424–428

    • model-based, 429–430

    • navigation, 421–423

    • object-oriented, 390–393, 404–407

    • organizing for, 374–375

    • patterns, 409

    • performance, 414, 424–426

    • playability, 433–434

    • preparing for, 377

    • principles of, 96–98

    • prototypes, 63–65, 68–69

    • for quality, 342

    • real-time, 426–428

    • recovery, 417

    • regression, 68, 403–404

    • scenario-based, 407

    • security, 414, 423–424

    • selective, 381

    • semantic, 420–421

    • smoke, 400–401

    • spiral illustration of, 375–376

    • static, 429

    • steps for, 376–377

    • structural, 97, 383–387, 397

    • system, 376, 377, 396

    • thread-based, 404

    • tools for, 50, 413, 415, 422, 430

    • unit, 48, 95, 376, 378–381

    • usability, 415–417, 430–432

    • use-based, 404

    • user, 255–256

    • user experience, 414–417

    • validation, 95, 373–377, 407–408

    • verification in, 373–374

    • virtual environments, 430–434

    • virtual keyboard input, 416

    • voice input and recognition, 416–417

    • WebApps, 418–426

    • white-box, 383–387, 397

  • 野外测试,414, 426–427

  • Testing in the wild, 414, 426–427

  • 测试报告,402

  • Test reports, 402

  • 测试集,633

  • Test sets, 633

  • 测试规范,402

  • Test specifications, 402

  • 第670页技术创新的理论阶段,585

  • Page 670Theory phase of technology innovation, 585

  • 基于线程的测试,404

  • Thread-based testing, 404

  • 威胁

    • 分析, 363

    • 在完整性测量中,483

    • 缓解, 357, 358

    • 建模, 357, 365–366

  • Threats

    • analysis of, 363

    • in integrity measurement, 483

    • mitigation of, 357, 358

    • modeling, 357, 365–366

  • TickIT审核方法,579

  • TickIT auditing method, 579

  • 时间分配,521

  • Time allocation, 521

  • 时间框, 42, 44, 45, 528–529

  • Time-boxes, 42, 44, 45, 528–529

  • 时间线图表,527

  • Time-line charts, 527

  • 时间窗口,508

  • Time window, 508

  • 工具

    • 捕捉/回放,403

    • 数据科学,631

    • 的函数,9

    • 界面设计,261

    • 对于移动应用程序,265, 267

    • 再造,562

    • 重构, 230, 561

    • 重组,564

    • 逆向工程, 555, 564

    • 调度,521

    • 为了安全,358、365

    • 社交网络,79

    • 静态分析,368

    • 测试, 50, 413, 415, 422, 430

    • 趋势, 599–600

    • 版本控制,445

  • Tools

    • capture/playback, 403

    • data science, 631

    • function of, 9

    • interface design, 261

    • for MobileApps, 265, 267

    • reengineering, 562

    • refactoring, 230, 561

    • restructuring, 564

    • reverse engineering, 555, 564

    • scheduling, 521

    • for security, 358, 365

    • social networking, 79

    • static analysis, 368

    • testing, 50, 413, 415, 422, 430

    • trends in, 599–600

    • version control, 445

  • 自上而下的整合,398–399

  • Top-down integration, 398–399

  • 全面质量管理 (TQM), 9, 349

  • Total quality management (TQM), 9, 349

  • 安全接触点,359

  • Touchpoints for security, 359

  • 有毒的团队环境, 77, 495

  • Toxic team environment, 77, 495

  • 可追溯性, 109–110, 383, 442

  • Traceability, 109–110, 383, 442

  • 可追溯性矩阵,109–110, 442

  • Traceability matrix, 109–110, 442

  • 追踪

    • 依赖项,445

    • 问题, 69, 446

    • 进展, 92

    • 时间表,528–529

    • 用户状态,258

    • 作为伞式活动,11

  • Tracking

    • dependencies, 445

    • issues, 69, 446

    • progress, 92

    • schedules, 528–529

    • state of user, 258

    • as umbrella activity, 11

  • 培训和教育, 342, 573

  • Training and education, 342, 573

  • 训练集、632、633

  • Training set, 632, 633

  • 超越的质量观,311

  • Transcendental view of quality, 311

  • 统一流程的过渡阶段,33

  • Transition phase of Unified Process, 33

  • 软件工程的趋势

    • 改变价值观念,592

    • 连通性和协作,587

    • 紧急需求,590–591

    • 全球化,587–588

    • 管理复杂性,588–589

    • 观察,586–587

    • 开源运动,592

    • 开放世界软件,589–590

    • 软趋势,587–592

    • 软件构建块,591–592

    • 人才组合,591

    • 技术, 584–585, 593–599

    • 与工具相关,599–600

  • Trends in software engineering

    • changing perceptions of value, 592

    • connectivity and collaboration, 587

    • emergent requirements, 590–591

    • globalization, 587–588

    • managing complexity, 588–589

    • observation of, 586–587

    • open source movement, 592

    • open-world software, 589–590

    • soft trends, 587–592

    • software building blocks, 591–592

    • talent mix, 591

    • technological, 584–585, 593–599

    • tools-related, 599–600

  • 触发器, 135, 150

  • Triggers, 135, 150

  • 可信度,431

  • Trustworthiness, 431

  • 伞式活动,10、11、21–22

  • Umbrella activities, 10, 11, 21–22

  • UML符号

    • 活动图, 146–148, 151–154, 223, 622–625

    • 原型,198

    • 类图, 120, 612–615

    • 通信图, 189, 190, 621–622

    • 组件图,177

    • 部署图, 177, 178, 615–616

    • 序列图, 148–149, 618–621

    • 状态图, 121, 150–151, 625–628

    • 泳道图, 151, 153–154

    • 用例图,119, 616–618

  • UML notation

    • activity diagrams, 146–148, 151–154, 223, 622–625

    • archetypes, 198

    • class diagrams, 120, 612–615

    • communication diagrams, 189, 190, 621–622

    • component diagrams, 177

    • deployment diagrams, 177, 178, 615–616

    • sequence diagrams, 148–149, 618–621

    • state diagrams, 121, 150–151, 625–628

    • swimlane diagrams, 151, 153–154

    • use case diagrams, 119, 616–618

  • 未调整的演员体重 (UAW), 517, 518

  • Unadjusted actor weight (UAW), 517, 518

  • 未调整用例权重 (UUCW), 517, 518

  • Unadjusted use case weight (UUCW), 517, 518

  • 不确定性,534

  • Uncertainty, 534

  • 统一建模语言(UML)

    • 演员, 131

    • 协会, 144, 154

    • 类模型,141–144

    • 依赖项,154

    • 发展, 32, 611

    • 对于多个观点,88

    • 符号(参见UML 符号)

    • 配置文件,131

  • Unified modeling language (UML)

    • actors in, 131

    • associations in, 144, 154

    • class models, 141–144

    • dependencies in, 154

    • development of, 32, 611

    • for multiple viewpoints, 88

    • notation (see UML notation)

    • profiles in, 131

  • 统一流程 (UP),31–33

  • Unified Process (UP), 31–33

  • 软件演化的统一理论,550

  • Unified theory for software evolution, 550

  • 单元测试, 48, 95, 376, 378–381

  • Unit testing, 48, 95, 376, 378–381

  • 无序分类变量,633

  • Unordered Categorical variables, 633

  • 不可预测的风险,535

  • Unpredictable risks, 535

  • 无监督学习,634

  • Unsupervised learning, 634

  • 可用性

    • 233、256 的定义

    • 工程学,236–237

    • 指南,257–259

    • 软件质量指标,483

    • 测试, 415–417, 430–432

  • Usability

    • definitions of, 233, 256

    • engineering, 236–237

    • guidelines for, 257–259

    • software quality metric, 483

    • testing, 415–417, 430–432

  • 使用场景,113–114, 271

  • Usage scenarios, 113–114, 271

  • 基于使用的测试,404

  • Use-based testing, 404

  • 用例图, 118, 119, 136, 137, 616–618

  • Use case diagrams, 118, 119, 136, 137, 616–618

  • 用例点 (UCP),517

  • Use case points (UCPs), 517

  • 用例

    • 创造,131–135

    • 定义, 31, 616

    • 的发展,114–118

    • 记录,135–137

    • 估计和,517–518

    • 例外情况,134–135

    • 正式, 127, 135

    • 识别事件,149–150

    • 待回答的问题,115

    • 细化, 135

    • 在需求收集中,113

    • 范围,135

    • 对于测试要求,382–383

    • 统一过程,31–33

    • 用于用户界面设计,247

  • Use cases

    • creating, 131–135

    • defined, 31, 616

    • development of, 114–118

    • documenting, 135–137

    • estimation and, 517–518

    • exceptions, 134–135

    • formal, 127, 135

    • identifying events with, 149–150

    • questions to be answered by, 115

    • refinement of, 135

    • in requirements gathering, 113

    • scope of, 135

    • for testing requirements, 382–383

    • in Unified Process, 31–33

    • for user interface design, 247

  • 用户体验测试,414–417

  • User experience testing, 414–417

  • 用户体验(UX)设计。另请参阅界面设计

    • 定义, 234

    • 175、234–237 的要素

    • 信息架构,235

    • 交互设计,236

    • 范围,234

    • 步骤,249–250

    • 可用性工程,236–237

    • 视觉设计,237

  • User experience (UX) design. see also Interface design

    • defined, 234

    • elements of, 175, 234–237

    • information architecture in, 235

    • interaction design in, 236

    • scope of, 234

    • steps for, 249–250

    • usability engineering in, 236–237

    • visual design in, 237

  • 用户交互设计,236

  • User interaction design, 236

  • 用户界面。另请参阅界面设计

    • 233、237、259–261 的可及性

    • 分析,243–249

    • 一致性, 240–241, 257

    • 建设, 243

    • 第 234 章

    • 原型, 62

    • 可用性, 233, 236–237, 256–259

    • 验证,243

  • User interface. see also Interface design

    • accessibility of, 233, 237, 259–261

    • analysis of, 243–249

    • consistency of, 240–241, 257

    • construction of, 243

    • interaction mechanisms in, 234

    • prototype of, 62

    • usability of, 233, 236–237, 256–259

    • validation of, 243

  • 用户建模,241、245–246

  • User modeling, 241, 245–246

  • 用户可观察的功能,146

  • User-observable functionality, 146

  • 用户角色,245–246

  • User personas, 245–246

  • 用户资料,131

  • User profiles, 131

  • 用户研究,244–245

  • User research, 244–245

  • 用户故事, 46, 48, 56, 58, 61–63, 67–68

  • User stories, 46, 48, 56, 58, 61–63, 67–68

  • 用户测试,255–256

  • User testing, 255–256

  • 用户对质量的看法,311

  • User view of quality, 311

  • 验证

    • 在沟通活动中,23

    • 努力, 521

    • 接口数量,243

    • 需求工程,105–106, 123–124

    • 运行时,123

    • 用户体验设计,250

  • Validation

    • in communication activity, 23

    • of effort, 521

    • of interface, 243

    • in requirements engineering, 105–106, 123–124

    • run-time, 123

    • in user experience design, 250

  • 验证测试,95、373–377、407–408

  • Validation testing, 95, 373–377, 407–408

  • 价值,改变观念,592

  • Value, changing perceptions of, 592

  • 基于价值的质量观,311

  • Value-based view of quality, 311

  • 可变性密集型系统,162, 590

  • Variability-intensive systems, 162, 590

  • 供应商管理,342

  • Vendor management, 342

  • 验证,123、373–374

  • Verification, 123, 373–374

  • 版本控制、445–446、457–458

  • Version control, 445–446, 457–458

  • 版本控制,445

  • Versioning, 445

  • 版本管理,446

  • Version management, 446

  • 多种观点,87–88、107–108

  • Viewpoints, multiple, 87–88, 107–108

  • 虚拟环境,430–434

  • Virtual environments, 430–434

  • 虚拟键盘输入,416

  • Virtual keyboard input, 416

  • 视觉设计, 237, 277

  • Visual design, 237, 277

  • 语音输入,416–417

  • Voice input, 416–417

  • 语音识别,416–417

  • Voice recognition, 416–417

  • 波动性, 118, 468

  • Volatility, 118, 468

  • 第671页行走的骷髅,203

  • Page 671Walking skeleton, 203

  • 演练, 326, 332

  • Walkthroughs, 326, 332

  • 瀑布模型,25–26, 55

  • Waterfall model, 25–26, 55

  • 导航方式(WoN),280–282

  • Ways of navigating (WoN), 280–282

  • WebApps(网络应用程序)

    • 的可达性,259

    • 美学设计, 277

    • 敏捷变革管理,453–458

    • 建筑设计, 192, 278–280

    • 226、282 的组件级设计

    • 内容设计,277–278

    • 设计金字塔,275–282

    • 平面设计, 237

    • 界面设计,275–276

    • 指标, 472, 473

    • 导航设计,280–282

    • 模式,291–292

    • 性能,424–426

    • 质量,282–285

    • 第424章 安全

    • 测试,418–426

    • 类型, 7

    • 可用性,257–259

  • WebApps (Web applications)

    • accessibility of, 259

    • aesthetic design of, 277

    • agile change management for, 453–458

    • architectural design of, 192, 278–280

    • component-level design for, 226, 282

    • content design of, 277–278

    • design pyramid for, 275–282

    • graphic design of, 237

    • interface design for, 275–276

    • metrics for, 472, 473

    • navigation design of, 280–282

    • patterns for, 291–292

    • performance of, 424–426

    • quality of, 282–285

    • security of, 424

    • testing, 418–426

    • types of, 7

    • usability of, 257–259

  • Web 服务描述语言 (WSDL),273

  • Web Services Description Language (WSDL), 273

  • 加权设备平台矩阵(WDPM),427

  • Weighted device platform matrix (WDPM), 427

  • 每类加权方法 (WMC),469

  • Weighted methods per class (WMC), 469

  • W 5 HH 原则,501

  • W5HH principle, 501

  • 白盒测试,383–387, 397

  • White-box testing, 383–387, 397

  • 工作分解结构 (WBS),526

  • Work breakdown structure (WBS), 526

  • 工作环境分析,248–249

  • Work environment analysis, 248–249

  • 工作流程。参见工艺流程

  • Work flow. see Process flow

  • 进行中的工作 (WIP),49

  • Work in progress (WIP), 49

  • 工作产品, 11, 86, 114, 402

  • Work products, 11, 86, 114, 402

  • 工作产品尺寸 (WPS),328

  • Work product size (WPS), 328

  • 工作任务。请参阅任务集

  • Work tasks. see Task sets